From RedHa@aol.com Fri Feb 02 09:33:11 1996
Received: from emout05.mail.aol.com (emout05.mail.aol.com [198.81.10.37]) by sys1.tapr.org (8.7.3/8.7.2) with SMTP id JAA04778 for <hfsig@tapr.org>; Fri, 2 Feb 1996 09:33:08 -0600 (CST)
From: RedHa@aol.com
Received: by emout05.mail.aol.com (8.6.12/8.6.12) id KAA12933 for hfsig@tapr.org; Fri, 2 Feb 1996 10:32:36 -0500
Date: Fri, 2 Feb 1996 10:32:36 -0500
Message-ID: <960202103234_134001137@emout05.mail.aol.com>
To: hfsig@tapr.org
Subject: Re: [HFSIG:847] HFSIG digest 228

Hi, Rick;

Tnx for both recent forwardings and the concern for our well being.  The
articles provide me with material for our local network association (WANA)
meetings.

We were a bit more isolated than usual for about a week, as the phone line to
the mobile home failed.  I replaced it Wed and spent a lot of time reading
the accumulated mail.

What are your thoughts on coordinating node operation: frequency, ERP,
directivity, etc.?

I'm working on a plan to put wx info on the local BBS, possibly moving to a
separate service located at the new LaCrosse NWS location when the ham
installation there nears completion.  My initial thought is to put the local
Zone service from MNDOT on the BBS, with revision once or twice per day.  If
you haven't explored it, connect on 726 1140, user name CUHOME, and password
MNDOT1.  HELPOUT will get you the menu, HELPOUT (command) will get directions
on using menu items, and INFO (command) will explain what each menu item
provides.  METRO will get you the local forecast, revised 3 or 4 times daily.
 Some commands are not explained well or at all.  One such is ZONE.  Try ZONE
(2 letter state identifier).  The zone info can be focused with ZONE MN/Z=95,
or other state and zone identifier.  It's provided by MNDOT, primarily
advertised to pilots, but includes a lot of general road and wx info.

Temp here was -30 F a while ago; up to -28 now!  I'd try to make ice cream,
but it would probably be grainy and I'd never get the dasher out.

Snowshoes have become essential.  Some of the frequently used tracks have
become hard enough to negotiate in boots.  I haven't had time to try the
skiis.  Now that the snow has firmed, they would probably be OK, but I don't
think they were appropriate in 20 inches of fresh powder.  Even the snowshoes
sank about a foot at first.

I'm working on two proposals at once, with deadlines today and Monday for
first draft.  Outside chores, like keeping cars running and the road open so
the XYL can escape, interfere a lot.  Sometimes I consider rejecting any
assignment requiring output in less than 30 days, so that I can avoid some of
the conflicts.

I recommend a book, "Flyfishing Through the Midlife Crises", Howell Raines.
 He models his maturing philosophy of life with the anology of transitioning
from the "Redneck way of fishing", to the dryfly purist who kills no fish.

Well, I better get back to work.  Hope school and all are going well for you
and Barb and bid you keep warm!

73 de Red

From chbrain@dircon.co.uk  Fri Feb 02 15:33:03 1996
Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by sys1.tapr.org (8.7.3/8.7.2) with SMTP id PAA18835 for <hfsig@tapr.org>; Fri, 2 Feb 1996 15:32:58 -0600 (CST)
Received: by felix.dircon.co.uk id AA18953
  (5.67b/IDA-1.5 for <hfsig@tapr.org>); Fri, 2 Feb 1996 21:32:29 GMT
Message-Id: <199602022132.AA18953@felix.dircon.co.uk>
Received: from gw2-138.pool.dircon.co.uk(194.112.35.138) by amnesiac via smap (V1.3)
	id sma018944; Fri Feb  2 21:32:20 1996
X-Sender: chbrain@popmail.dircon.co.uk (Unverified)
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 02 Feb 1996 21:05:09 +0000
To: hfsig@tapr.org
From: chbrain@dircon.co.uk (Charles Brain)
Subject: 8ary FSK

In case anyone is interested, I have included a brief T.D of my modem. It
is based very heavily on Adrian Nash's Piccolo modem.  It's my first DSP
project so it probably not the best implementation!!!!

--------------------------------------------------- Snip
--------------------------------------------------------

This is a brief description of how the 8ary FSK modem has been implemented
on a TMS320C50 EVM (not DSK).

1) The input signal is sampled at 8k samples per second.
2) The signal is mixed with a sine and cos wave at 1625Hz. The 1625hz is
   generated with a lookup table, the transmit tones also use this lookup table.
   This moves the 8 tones symetrically around 0 Hz. As the signals are now
   complex their frequency sign is not lost.
3) The I and Q channel that have been generated are now low pass filtered using
   a 32 tap FIR filter with a cutoff freqeuncy of 1khz. This filter also
   decimates the signal by four and places it's output into a 16 entry
   circular buffer. The effective sample rate is now 2Ks/s.
4) The 16 samples from the I channel are placed in the 16 real input locations 
   of a 16 point FFT. The 16 samples from the Q channel are placed in the 16
   complex input locations of the 16 point complex FFT.
5) The FFT is run at each fourth input sample (2Khz). The input buffer to the
   FFT is in fact 1 bit period (8ms) in length, a happy coincidance.
6) After each FFT the magnitude squared of each of the wanted frequency bins 
   is calculated(square roots are expensive to calculate). Not all bins are
used.
   When a bit completely fills the input window, the bin magnitude is at a
maximum.
7) The bin with the maximum output is divided by the sum of the magnitudes of  
   all the other wanted bins. This waveform contains a component at the symbol
   rate. The result is filtered with a BPF centered at 125Hz (symbol rate). 
   This signal is used to lock an NCO to the symbol rate. This locking code 
   may need more work as I have not yet tested it on poor channels.
8) When a symbol epoch arrives the bin with the largest magnitude is found and
   its symbol value is written to the host port.
9) Data carrier detect is generated from the bit sync 'circuit', when bit sync 
   is achieved DCD is signalled to the host P.C. This provides a fast DCD which
   is essential for rapid scanning.

Notes.
Although the main part of the code operates at 8khz the FFT, magnitude
calculation, 
bit sync and symbol epoch calculation occur at 2khz, i.e they are scheduled. 
On the first 8k interrupt the FFT runs, next interrupt the magnitude
calculation 
runs etc. 
The FFT algorithm is taken from the TI manual and uses a rectangular window.
The filters were designed using PC-DSP and parts of the modem were simulated
using
PC-SIM.
At present the whole modem operates within the interrupt. Future plans are
to add 
some form of whitening filter. There are plenty of spare cycles left! 
It has been tested against the NTIA test waveforms (clean tones) and manages to 
achieve word sync and hold it. I haven't tried the degraded tones yet. 
Voting and Golay error correction are done within the P.C. 

The unused frequency bins could be used for frequency/doppler correction. I am
not sure what frequency tolerance this modem requires.

Charles G4GUO

From karn@qualcomm.com Fri Feb 02 23:22:48 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by sys1.tapr.org (8.7.3/8.7.2) with ESMTP id XAA07806 for <hfsig@tapr.org>; Fri, 2 Feb 1996 23:22:46 -0600 (CST)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.3/8.7.2/1.4) id VAA10891; Fri, 2 Feb 1996 21:22:10 -0800 (PST)
Date: Fri, 2 Feb 1996 21:22:10 -0800 (PST)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199602030522.VAA10891@servo.qualcomm.com>
To: chbrain@dircon.co.uk (Charles Brain)
CC: hfsig@tapr.org
In-reply-to: <199602022132.AA18953@felix.dircon.co.uk> (chbrain@dircon.co.uk)
Subject: Re: [HFSIG:849] 8ary FSK

Charles,

Your system sounds most interesting. It's pretty much along the lines
of the system I've been contemplating; it differs mainly in the
numbers. Do you have any performance figures? I'm really curious.

I have been thinking of much larger values of m, like 128 or 256, to
improve Eb/N0 performance. Coding over a noncoherent channel behaves
very differently than on a coherent channel (e.g., BPSK). You gain by
adding a little coding to both. But while the coherent channel
asymptotically decreases in Eb/N0 requirements as you decrease the
code rate, the noncoherent channel 'bottoms out' in its Eb/N0
requirements at a certain critical code rate and then increases again
as the code rate is further lowered. This is due to the inherent
nonlinearities in noncoherent demodulation; as you decrease the code
rate below the optimum you force the demodulator to work below its
threshold.

The minimum Eb/N0 obtained at the optimum code rate is a strong
function of m, the number of "tones", with larger m always giving
better performance (assuming the symbol time doesn't become so long as
to exceed the coherence time of the channel.)

Nevertheless, uncoded noncoherent m=8 is already better on the Eb/N0
score than uncoded *coherent* BPSK, which is not too shabby. I'm told
that 8-ary FSK is common in military HF modems.

I differ somewhat in my approach to synchronization. I need some sort
of synchronization vector, which I plan to interleave with the data.
Otherwise a fade at the front of the packet could clobber the sync,
leaving the rest of the packet strong but unusable.

My idea here is to slide a series of FFTs spaced at the separation of
the individual sync symbols across the incoming audio in a buffer.
The step would be perhaps 1/4 symbol, narrow enough to have a good
chance of spotting the energy in a weak packet but not so narrow as to
make the CPU requirements prohibitive.

After FFTing and taking bin energy values, I sum all the energies in
the bins corresponding to where the sync symbols should be, and from
that I subtract the energies in all the other bins. If the result is
larger than a threshold, I declare initial lock and begin a finer
search in time to maximize this value. Now I know exactly where the
packet begins and ends and also where the individual symbols begin and
end. I then run my FFTs to recover the data symbols, producing in each
case a set of soft decision values for the Viterbi or Fano decoder
that follows. This I do for each bit within a symbol by summing all
the FFT energy bins for which the bit in question is a "1" and
subtracting all those for which the bit is a "0". This gives better
soft metrics than just taking the energy bin with the largest
magnitude and spitting out the hard-decoded log2(m) data bits that
correspond to it.

For large m, I could probably improve CPU performance considerably
during sync search by just correlating with the appropriate sinusoids
in the appropriate places and subtracting off total received energy
from the sum of the correlator outputs.

With modern clocks I shouldn't have to run any kind of tracking loop
to recover symbol timing once I've acquired synchronization. In the
event of a small symbol rate mismatch between sender and receiver, the
interleaving of the sync vector with the data should help find the
best compromise timing. Of course, the size of the data block will
have to be limited to keep frequency errors from accumulating
indefinitely.

Oh, and I'll probably use a Hamming window on each symbol at both the
transmitter and receiver to control spectral shaping and to mitigate
intersymbol interference effects.

Phil

From chbrain@dircon.co.uk  Sun Feb 04 03:13:39 1996
Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by sys1.tapr.org (8.7.3/8.7.2) with SMTP id DAA20941 for <hfsig@tapr.org>; Sun, 4 Feb 1996 03:13:37 -0600 (CST)
Received: by felix.dircon.co.uk id AA26783
  (5.67b/IDA-1.5 for <hfsig@tapr.org>); Sun, 4 Feb 1996 09:13:34 GMT
Message-Id: <199602040913.AA26783@felix.dircon.co.uk>
Received: from gw2-141.pool.dircon.co.uk(194.112.35.141) by amnesiac via smap (V1.3)
	id sma026773; Sun Feb  4 09:13:13 1996
X-Sender: chbrain@popmail.dircon.co.uk (Unverified)
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 04 Feb 1996 08:45:45 +0000
To: hfsig@tapr.org
From: chbrain@dircon.co.uk (Charles Brain)
Subject: Re: [HFSIG:850] Re: 8ary FSK

>Charles,
>
>Your system sounds most interesting. It's pretty much along the lines
>of the system I've been contemplating; it differs mainly in the
>numbers. Do you have any performance figures? I'm really curious.
>
Hello Phil,
 I am afraid that at present I have no accurate way of measuring performance.
This is one of the reasons I need to do further work on the sync. The setup I am
using is a C50 EVM for the modem and a C50 DSK for a test generator. I have
plans
to use the DSK as a crude channel simulator, take the audio output of the
EVM and
set its S/N in the DSK add a random time offset (otherwise the modem doesn't
have to 
search for sync) and send it back for decoding.

I am also trying to improve my simulation capabilities, this weekend I have
been porting
an H.F Channel simulator written in C by Eric Johnson of NMSU to a form where 
I can call it from the macro language within PC-DSP, this allows me to take
a signal
add multipath/fading and doppler spread and pass it on to a simulated modem.

When I get this going I will be able to investigate the effects of different
window functions
on multipath.

Synchronization has proven to be the part that has given me the most trouble!

Do you plan to send a single interleaved block of data in each frame or a
number of
blocks with selective repeats at the receiving end like some military modems
do? Aka FS1052
Appendix B ?
Also how are you going to synchronize to the data, will it be a bi-product
of the decoder 
or are you going to use a synch vector such as a Barker sequence?

I assume you are not using phase information (from your description), and
won't be using
Ungerbock codes. There was an interesting article, I think it was repeated
in Nordic 95 about
the use of Ungerbock codes and parallel tone modems by Steve Cook. The paper
originally 
appeared in the IEE York conferance on H.F in 1994.

By the way I downloaded your Digital Audio Clips from your WWW page so I
know what the real
KA9Q sounds like !

I look forward to hearing you future explots and maybe I'll get to port your
modem to my DSP
platform one day!

Regards Charles G4GUO.

From forrerj@ucs.orst.edu  Sun Feb 04 18:07:40 1996
Received: from ucs.orst.edu (root@UCS.ORST.EDU [128.193.4.5]) by sys1.tapr.org (8.7.3/8.7.2) with SMTP id SAA21773 for <HFSIG@TAPR.ORG>; Sun, 4 Feb 1996 18:07:32 -0600 (CST)
Received: from p07.t0.monrotel.com by ucs.orst.edu; (5.65v3.2/1.1.8.2/24Sep94-1201PM)
	id AA03512; Sun, 4 Feb 1996 16:07:11 -0800
Message-Id: <9602050007.AA03512@ucs.orst.edu>
X-Sender: forrerj@ucs.orst.edu
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 04 Feb 1996 16:10:00 -0800
To: HFSIG@tapr.org
From: forrerj@ucs.orst.edu (Johan Forrer)
Subject: EXPERIMENTAL HF MODEM BEACON PROJECT

Hi all,

I now have my hardware set up and ready to run different modem beacons on
HF. The beacon runs in "attended" mode and by pre-arrangement. I can work on
28, 21, 14, 7 and 3.5 MHz.

The 15-tone modem has NOS capabilities, so a connection is possible. The
SLOWBPSK modem is a beacon only, however, manual operation allows
keyboard-to-keyboard QSO's. I will be happy to
activate the sytem/beacon if anyone is interested in running some tests.

-- Johan, KC7WW   

From FORRERJ@frl.orst.edu Wed Feb 07 11:48:04 1996
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by tapr.org (8.7.3/8.7.2) with SMTP id LAA13908 for <hfsig@tapr.org>; Wed, 7 Feb 1996 11:48:01 -0600 (CST)
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.118.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with ESMTP id JAA25982 for <hfsig@tapr.org>; Wed, 7 Feb 1996 09:45:03 -0800
Received: from FRL/SpoolDir by frl.orst.edu (Mercury 1.21);
    7 Feb 96 09:55:17 PST8PDT
Received: from SpoolDir by FRL (Mercury 1.21); 7 Feb 96 09:54:58 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Wed, 7 Feb 1996 09:54:49 -0800
Subject:       SLOW BPSK NEWS
Priority: normal
X-mailer: Pegasus Mail v3.22
Message-ID: <1D82CB45456@frl.orst.edu>

Hi all,

Some exciting news that we want to share. 

Pawel, SP9VRC is presently at CERN, Switzerland, and have been patiently 
listening for my (KC7WW, Monroe, Oregon) slow speed BPSK transmissions on 
20 meters. My setup consists of a DSP56002EVM running Pawel's SLOWBPSK 
program, an an ICOM 751 on LSB mode, RF output is 10W to a Butternut 
vertical. 

For the first time; yesterday looked like Pawel got something - not yet 
confirming callsigns, but that is only a matter of time. Here is what he 
e-mailed me:

                     ----------------------------
Well, this time something did work. Today at 16:20 UTC I got a long lock
(I didn't need to wait long for it) and then in the garbage characters
I could clearly see CQ (with capital letters) being sent at least four 
times.
They were not in a row but at a distance of some 60-80 characters.
I could see as well the space before or after them.

I was listenning with the TS-440 and I used the narrow filter
(I didn't try the wide filter at that time). I was not able to
hear any audible signal by ear.
However, I noticed there is some weak but regular CW being sent on this
or close frequency - it that you ?

I left the setup running and the output is being recorded on a file.
I will send you the file later.
I have made a schedule at 20:00 UTC on 14.180 USB voice with Danie
every day this week and weekend.

I'm sure I would capture more text if we had the FEC and good block-sync.
With asynchronous transmition one fake bit can spoil several
characters...

Pawel
                    ---------------------

Sounds like fun, does'nt it ?

--Johan, KC7WW
                    

From cbuttsch@slonet.org Wed Feb 07 20:29:34 1996
Received: from biggulp.callamer.com (cbuttsch@biggulp.callamer.com [199.74.141.2]) by tapr.org (8.7.3/8.7.2) with SMTP id UAA05105 for <hfsig@tapr.org>; Wed, 7 Feb 1996 20:29:31 -0600 (CST)
Received: (from cbuttsch@localhost) by biggulp.callamer.com (8.6.12/8.6.9-callamer-rdw080995) id SAA16148; Wed, 7 Feb 1996 18:25:53 -0800
Date: Wed, 7 Feb 1996 18:25:52 -0800 (PST)
From: Clifford Buttschardt <cbuttsch@slonet.org>
To: Johan Forrer <FORRERJ@frl.orst.edu>
cc: hfsig@tapr.org
Subject: Re: [HFSIG:853] SLOW BPSK NEWS
In-Reply-To: <1D82CB45456@frl.orst.edu>
Message-ID: <Pine.OSF.3.91.960207182038.13730B-100000@biggulp.callamer.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Johan.  Congratulations on the slow speed BPSK experiments.  First, I 
was not aware that you had these going on twenty meters.  As you know, the
one watt BPSK beacon is running on 187.65 KHz in the experimenters band.
It was printed out 1600 miles---San Luis Obispo, CA to Aitkin, Minn.  
    I mention this simply to emphasize a great deal is being done and 
even I seem not able to keep up!  73  Cliff Buttschardt  W6HDO

From jbloom@arrl.org Thu Feb 08 10:08:51 1996
Received: from mgate.arrl.org (root@mgate.arrl.org [205.217.201.2]) by tapr.org (8.7.3/8.7.2) with SMTP id KAA08028 for <hfsig@tapr.org>; Thu, 8 Feb 1996 10:08:48 -0600 (CST)
Received: from home by mgate.arrl.org with smtp
	(Smail3.1.29.1 #3) id m0tkYpe-000RAnC; Thu, 8 Feb 96 11:04 EST
Received: by home with Microsoft Mail
	id <01BAF615.CF258A40@home>; Thu, 8 Feb 1996 11:08:43 -0500
Message-ID: <01BAF615.CF258A40@home>
From: Jon Bloom <jbloom@arrl.org>
To: "'hfsig@tapr.org'" <hfsig@tapr.org>
Subject: FW: demodulator for MSK signals
Date: Thu, 8 Feb 1996 11:08:42 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Can any of you HFSIG gurus help this fellow?

-- Jon, KE3Z
jbloom@arrl.org

----------
From: 	Mr. Brooke Clarke[SMTP:brooke@pacific.net]
Sent: 	Wednesday, February 07, 1996 11:25 PM
To: 	jbloom@arrl.org
Subject: 	demodulator for MSK signals

I have been studying Chapter 18 of the '96 Handbook.  I would like to buy 
or if not available build a DSP demodulator that can demodulate the MSK 
signals on the Coast Guard LF beacon stations.  These stations are 
transmitting Differential Global Positioning System (DGPS) data.

The lower cost MSK receivers on the market use FSK demodulators.  My 
application for the signals is inland where the signals are weak and I 
believe I need a close to optimal demodulator.  I can hear signals from a 
number of beacon stations with my ear so expect that a true MSK 
demodulator would give me usable data.

Could you point me toward a commercial product, a ham type kit, or 
further reading material?

Thanks,
Brooke
N6GCE




From mwheatle@TRSystems.com Thu Feb 08 10:14:48 1996
Received: from www (www.trsystems.com [206.232.131.2]) by tapr.org (8.7.3/8.7.2) with SMTP id KAA08175 for <hfsig@tapr.org>; Thu, 8 Feb 1996 10:14:45 -0600 (CST)
Received: by www with Microsoft Mail
	id <01BAF616.BF4232D0@www>; Thu, 8 Feb 1996 11:15:26 -0500
Message-ID: <c=US%a=_%p=TRSystems%l=WEBSERVER960208111516AX006D00@www>
From: "Wheatley, Maurice" <mwheatle@TRSystems.com>
To: "'hfsig'" <hfsig@tapr.org>
Subject: DSP Tools
Date: Thu, 8 Feb 1996 11:15:13 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi everybody,
I'm new to the SIG and just getting into this interesting DSP stuff.  Was=
 wondering if anybody has any suggestions on software design/simulation p=
ackages for dsp designs that don't require a second mortgage on the house=
:-)
I've got Math CAD and am looking at QEDesign.
Also how about book recommendations. Best I've found so far is Marvin Fre=
rking's "Digital Signal Processing in Communications Systems".
Any thoughts or referals to past threads would be appreciated. Thanks!

Moe AE4JY
mwheatle@trsystems.com

From chbrain@dircon.co.uk  Thu Feb 08 12:39:20 1996
Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by tapr.org (8.7.3/8.7.2) with SMTP id MAA14462 for <hfsig@tapr.org>; Thu, 8 Feb 1996 12:39:10 -0600 (CST)
Received: by felix.dircon.co.uk id AA15851
  (5.67b/IDA-1.5 for <hfsig@tapr.org>); Thu, 8 Feb 1996 18:37:48 GMT
Message-Id: <199602081837.AA15851@felix.dircon.co.uk>
Received: from gw2-193.pool.dircon.co.uk(194.112.35.193) by amnesiac via smap (V1.3)
	id sma015653; Thu Feb  8 18:35:39 1996
X-Sender: chbrain@popmail.dircon.co.uk
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 08 Feb 1996 18:07:19 +0000
To: hfsig@tapr.org
From: chbrain@dircon.co.uk (Charles Brain)
Subject: Re: [HFSIG:856] DSP Tools

>Hi everybody,
>I'm new to the SIG and just getting into this interesting DSP stuff.  Was
wondering if anybody has any suggestions on software design/simulation
packages for dsp designs that don't require a second mortgage on the house:-)
>I've got Math CAD and am looking at QEDesign.
>Also how about book recommendations. Best I've found so far is Marvin
Frerking's "Digital Signal Processing in Communications Systems".
>Any thoughts or referals to past threads would be appreciated. Thanks!
>
>Moe AE4JY
>mwheatle@trsystems.com
>
>
Hello Moe,

Well I use PC-DSP and PC-SIM to design filters etc cost about $200 
there www page is :-

    http://www.dspsolutions.com

I am working on modifying some HF channel simulator code written by
Eric Johnson of NMSU so I can call it from within the package.

Regards Charles G4GUO

From srbible@mindport.net  Thu Feb 08 18:15:45 1996
Received: from polaris.mindport.net (root@polaris.mindport.net [205.219.167.2]) by tapr.org (8.7.3/8.7.2) with SMTP id SAA29699 for <hfsig@tapr.org>; Thu, 8 Feb 1996 18:15:38 -0600 (CST)
Received: from polaris.mindport.net (synapse-12.mindport.net [205.219.167.31]) by polaris.mindport.net (8.6.12/8.6.12) with SMTP id TAA27985 for <hfsig@tapr.org>; Thu, 8 Feb 1996 19:15:35 -0500
Date: Thu, 8 Feb 1996 19:15:35 -0500
Posted-Date: Thu, 8 Feb 1996 19:15:35 -0500
Message-Id: <199602090015.TAA27985@polaris.mindport.net>
X-Sender: srbible@mail.mindport.net
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: hfsig@tapr.org
From: srbible@mindport.net (Steven R. Bible)
Subject: Re: [HFSIG:856] DSP Tools

>Hi everybody,
>I'm new to the SIG and just getting into this interesting DSP stuff.  Was
wondering if anybody has any suggestions on software design/simulation
packages for dsp designs that don't require a second mortgage on the house:-)
>I've got Math CAD and am looking at QEDesign.
>Also how about book recommendations. Best I've found so far is Marvin
Frerking's "Digital Signal Processing in Communications Systems".
>Any thoughts or referals to past threads would be appreciated. Thanks!

Hello Moe,

I really enjoy the Frerking Book.  I am still studying it and I would like
to construct a DSP based receiver.  Both Harris and ADI have chips that are
designed for digital IF.  

    Harris - http://www.semi.harris.com/

        AN9509.1  Digital IF Sub Sampling Using the HI5702, HSP45116 
                  and HSP43220

        HSP50016  Digital Down Converter

        TB330     Higher Speed Clock Rates Help Ease Filtering Requirements 
                  in Communication D/As

        AN9401    Reducing the Minimum Decimation Rate of the HSP50016 
                  Digital Down Converter

   Analog Devices - http://www.analog.com/

        ADSP-21060/ADSP-21062 Super Harvard Architecture Computers

The Frerking Book does an excellent job of bringing you up from digital
basics to digital communications (not data communications which usually
refers to LAN based protocols).

I spent some time surfing the web for books.  I created a temporary
bibliography of books on Spread Spectrum, DSP, Digital Communications, and
MATLAB.  You can take a look at:

    http://www.mindport.net/~srbible/biblio.html

I will be moving this page to the www.tapr.org site soon.  In the mean time,
please take a look and give comments.  You can see the books that I have
found in the above catagories.  You can click on the titles and you will go
to the publishers web pages that describes the books in detail.  I have also
included some technical bookstores at the bottom of the page.  I have had
excellent results with the San Diego Technical Bookstore (no peculinary
interest, just a happy customer).  

As for DSP development platforms.  Both TI (www.ti.com) and Motorola
(www.motorola.com) have inexpensive DSP Starter Kits (DSK) (TI) or
Evaluation Modules (EVM) (Motorola).  The TI C5X DSK (p/n TMDS3200051) costs
$99.00 and the Motorola EVM560002 costs $149.00.  I own the later and have
the former on order.

The best place to read about the EVM56002 is Johan Forrer's KC7WW August
1995 QEX article (you can order back issues from the ARRL).  (BTW - Johan
moderates this list. Thanks for the article Johan!)  

As for matimatical simulators, there's PC-DSP for which you can download an
evaluation copy from the 'net (http://www.dspsolutions.com/), and there's
MATLAB.  There's a book entitled "Digital Signal Processing: A Laboratory
Approach Using PC-DSP, 2/e" (see my biblio web page).  There's also another
book for MATLAB entitled "Computer-Based Exercises for Signal Processing
Using MATLAB, 1/e."  

Hope this helps.

73,

 - Steve, N7HPR

srbible@mindport.net
n7hpr@amsat.org
n7hpr@tapr.org

From ssykes@ns2.emirates.net.ae Fri Feb 09 02:49:57 1996
Received: from ns2.emirates.net.ae (ns2.emirates.net.ae [194.170.1.7]) by tapr.org (8.7.3/8.7.2) with SMTP id CAA25565 for <hfsig@tapr.org>; Fri, 9 Feb 1996 02:49:52 -0600 (CST)
Received: from csa029.emirates.net.ae by ns2.emirates.net.ae (5.x/SMI-SVR495081401)
	id AC26511; Fri, 9 Feb 1996 12:49:44 +0400
Message-Id: <9602090849.AC26511@ns2.emirates.net.ae>
X-Sender: ssykes@emirates.net.ae
X-Mailer: Windows Eudora Light Version 1.5.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 09 Feb 1996 12:46:26 +0400
To: hfsig@tapr.org
From: Stephan Sykes <ssykes@ns2.emirates.net.ae>
Subject: Re: [HFSIG:853] SLOW BPSK NEWS

What frequency on 20 are you using?
 
At 11:50 AM 2/7/96 -0600, you wrote:
>Hi all,
>
>Some exciting news that we want to share. 
>
>Pawel, SP9VRC is presently at CERN, Switzerland, and have been patiently 
>listening for my (KC7WW, Monroe, Oregon) slow speed BPSK transmissions on 
>20 meters. My setup consists of a DSP56002EVM running Pawel's SLOWBPSK 
>program, an an ICOM 751 on LSB mode, RF output is 10W to a Butternut 
>vertical. 
>
>For the first time; yesterday looked like Pawel got something - not yet 
>confirming callsigns, but that is only a matter of time. Here is what he 
>e-mailed me:
>
>                     ----------------------------
>Well, this time something did work. Today at 16:20 UTC I got a long lock
>(I didn't need to wait long for it) and then in the garbage characters
>I could clearly see CQ (with capital letters) being sent at least four 
>times.
>They were not in a row but at a distance of some 60-80 characters.
>I could see as well the space before or after them.
>
>I was listenning with the TS-440 and I used the narrow filter
>(I didn't try the wide filter at that time). I was not able to
>hear any audible signal by ear.
>However, I noticed there is some weak but regular CW being sent on this
>or close frequency - it that you ?
>
>I left the setup running and the output is being recorded on a file.
>I will send you the file later.
>I have made a schedule at 20:00 UTC on 14.180 USB voice with Danie
>every day this week and weekend.
>
>I'm sure I would capture more text if we had the FEC and good block-sync.
>With asynchronous transmition one fake bit can spoil several
>characters...
>
>Pawel
>                    ---------------------
>
>Sounds like fun, does'nt it ?
>
>--Johan, KC7WW
>                    
>
>
Stephan Sykes
ssykes@emirates.net.ae

From forrerj@ucs.orst.edu Fri Feb 09 10:39:10 1996
Received: from ucs.orst.edu (forrerj@UCS.ORST.EDU [128.193.4.5]) by tapr.org (8.7.3/8.7.2) with SMTP id KAA13593 for <hfsig@tapr.org>; Fri, 9 Feb 1996 10:39:07 -0600 (CST)
Received: by ucs.orst.edu; (5.65v3.2/1.1.8.2/24Sep94-1201PM)
	id AA11287; Fri, 9 Feb 1996 08:38:54 -0800
Date: Fri, 9 Feb 1996 08:38:53 -0800 (PST)
From: Johan Forrer <forrerj@ucs.orst.edu>
To: hfsig@tapr.org
Subject: Re: [HFSIG:859] Re: SLOW BPSK NEWS
In-Reply-To: <9602090849.AC26511@ns2.emirates.net.ae>
Message-Id: <Pine.OSF.3.91.960209083439.28524A-100000@ucs.orst.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


Hi Stephen,


We are on 14.100, closeby the international CW beacon frequency. Set 
your dial for a readout of 14.100 on LSB mode. The actual carrier is some 
1650 Hz lower down from 14.100. Use the CW beacons as a reference for 
propation status.

The beacon is on for a few hours between about 12.00 - 20.00 UTC. I can 
arrange to have it on for other periods as well.

73's

--Johan, KC7WW



On Fri, 9 Feb 1996, Stephan 
Sykes wrote:

> What frequency on 20 are you using?
>  
> At 11:50 AM 2/7/96 -0600, you wrote:
> >Hi all,
> >
> >Some exciting news that we want to share. 
> >
> >Pawel, SP9VRC is presently at CERN, Switzerland, and have been patiently 
> >listening for my (KC7WW, Monroe, Oregon) slow speed BPSK transmissions on 
> >20 meters. My setup consists of a DSP56002EVM running Pawel's SLOWBPSK 
> >program, an an ICOM 751 on LSB mode, RF output is 10W to a Butternut 
> >vertical. 
> >
> >For the first time; yesterday looked like Pawel got something - not yet 
> >confirming callsigns, but that is only a matter of time. Here is what he 
> >e-mailed me:
> >
> >                     ----------------------------
> >Well, this time something did work. Today at 16:20 UTC I got a long lock
> >(I didn't need to wait long for it) and then in the garbage characters
> >I could clearly see CQ (with capital letters) being sent at least four 
> >times.
> >They were not in a row but at a distance of some 60-80 characters.
> >I could see as well the space before or after them.
> >
> >I was listenning with the TS-440 and I used the narrow filter
> >(I didn't try the wide filter at that time). I was not able to
> >hear any audible signal by ear.
> >However, I noticed there is some weak but regular CW being sent on this
> >or close frequency - it that you ?
> >
> >I left the setup running and the output is being recorded on a file.
> >I will send you the file later.
> >I have made a schedule at 20:00 UTC on 14.180 USB voice with Danie
> >every day this week and weekend.
> >
> >I'm sure I would capture more text if we had the FEC and good block-sync.
> >With asynchronous transmition one fake bit can spoil several
> >characters...
> >
> >Pawel
> >                    ---------------------
> >
> >Sounds like fun, does'nt it ?
> >
> >--Johan, KC7WW
> >                    
> >
> >
> Stephan Sykes
> ssykes@emirates.net.ae
> 
> 

From mwheatle@TRSystems.com Fri Feb 09 14:24:44 1996
Received: from www (www.trsystems.com [206.232.131.2]) by tapr.org (8.7.3/8.7.2) with SMTP id OAA22566 for <hfsig@tapr.org>; Fri, 9 Feb 1996 14:24:41 -0600 (CST)
Received: by www with Microsoft Mail
	id <01BAF702.D3E81EB0@www>; Fri, 9 Feb 1996 15:25:22 -0500
Message-ID: <c=US%a=_%p=TRSystems%l=WEBSERVER960209152514AB005400@www>
From: "Wheatley, Maurice" <mwheatle@TRSystems.com>
To: "'hfsig'" <hfsig@tapr.org>
Subject: TNX for help
Date: Fri, 9 Feb 1996 15:25:11 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Thanks to Charles and Steven for the help. The
http://www.mindport.net/~srbible/biblio.html site is a great launching po=
int
for technical book sources.  Now to figure out how to funnel all that inf=
ormation into my head so I can contribute something useful someday. Thank=
s again.

Moe  AE4JY
mwheatle@trsystems.com

From forrerj@ucs.orst.edu  Sat Feb 10 23:05:08 1996
Received: from ucs.orst.edu (root@UCS.ORST.EDU [128.193.4.5]) by tapr.org (8.7.3/8.7.2) with SMTP id XAA07574 for <hfsig@tapr.org>; Sat, 10 Feb 1996 23:05:05 -0600 (CST)
Received: from p01.t0.monrotel.com by ucs.orst.edu; (5.65v3.2/1.1.8.2/24Sep94-1201PM)
	id AA20014; Sat, 10 Feb 1996 21:04:24 -0800
Message-Id: <9602110504.AA20014@ucs.orst.edu>
X-Sender: forrerj@ucs.orst.edu
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 10 Feb 1996 21:08:37 -0800
To: hfsig@tapr.org
From: forrerj@ucs.orst.edu (Johan Forrer)
Subject: HF channel simulator
Cc: kurpiers@zeus.uet.e-technik.th-darmstadt.de

Dear Alexander,

Thank you very much for your posting of the HF channel simulator. It looks
like a wonderful tool and I am sure we are only at the very beginning of
this kind of exploration, at least as amateurs.
Fortunately for me, the bit of comments in German was no problem.

I looked a bit at the code and have a few questions that I would appreciate
your comments: Which assembler was used? It obviously is not the DSK
assembler because that cannot even handle simple directives such as ".equ"
or compound statements such as "label+4". I did tried Speech Corporation's
TASM for the 320C25 as used with the DSP93, but that terminates in error
because of some internal table overflow. (If anyone could tell me how to
increase the size of the "bpoutp" I would be grateful).

Do you perhaps know of a PD assembler that would assemble the program?

The other bit of information that would be quite useful to know beforehand
is the memory requirements. It so happens that I also have an LED bargraph
at port 0 and external program memory located at 1000-EFFFh, so I may just
be lucky to be able to run the simulator on my platform without too much
problems.

Thanks again for your valued contribution.

--Johan, KC7WW

From danie.brynard@pixie.co.za  Sun Feb 11 02:44:51 1996
Received: from f15.pix.za (root@f15.pix.za [196.11.62.108]) by tapr.org (8.7.3/8.7.2) with ESMTP id CAA20596 for <hfsig@tapr.org>; Sun, 11 Feb 1996 02:44:43 -0600 (CST)
Received: from net-13.pta.pix.za (net-3.pta.pix.za [196.11.63.3]) by f15.pix.za (8.7.1/8.6.11) with SMTP id KAA18842 for <hfsig@tapr.org>; Sun, 11 Feb 1996 10:46:47 +0200
Message-Id: <199602110846.KAA18842@f15.pix.za>
X-Sender: pak03226@pixie.co.za
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 11 Feb 1996 10:44:26 +0200
To: hfsig@tapr.org
From: danie.brynard@pixie.co.za (Danie Brynard)
Subject: Re: [HFSIG:853] SLOW BPSK NEWS

REGARDING SLOW BPSK between CERN and Pretoria (ZS):

Well all I can report is that we have not been successfull yet :-( If there
are any other guys interested in working SLOW BPSK with me let me know
please ! I can work the east coast of the USA quite easily but the west
coast seems to be a problem. (were Johan kc7ww is)

I can also hear the Italians VERY often so are their any Italian SLOW BPSK
guys out there ?

73 Danie zs6awk

>Hi all,
>
>Some exciting news that we want to share. 
>
>Pawel, SP9VRC is presently at CERN, Switzerland, and have been patiently 
>listening for my (KC7WW, Monroe, Oregon) slow speed BPSK transmissions on 
>20 meters. My setup consists of a DSP56002EVM running Pawel's SLOWBPSK 
>program, an an ICOM 751 on LSB mode, RF output is 10W to a Butternut 
>vertical. 
>
>For the first time; yesterday looked like Pawel got something - not yet 
>confirming callsigns, but that is only a matter of time. Here is what he 
>e-mailed me:
>
>                     ----------------------------
>Well, this time something did work. Today at 16:20 UTC I got a long lock
>(I didn't need to wait long for it) and then in the garbage characters
>I could clearly see CQ (with capital letters) being sent at least four 
>times.
>They were not in a row but at a distance of some 60-80 characters.
>I could see as well the space before or after them.
>
>I was listenning with the TS-440 and I used the narrow filter
>(I didn't try the wide filter at that time). I was not able to
>hear any audible signal by ear.
>However, I noticed there is some weak but regular CW being sent on this
>or close frequency - it that you ?
>
>I left the setup running and the output is being recorded on a file.
>I will send you the file later.
>I have made a schedule at 20:00 UTC on 14.180 USB voice with Danie
>every day this week and weekend.
>
>I'm sure I would capture more text if we had the FEC and good block-sync.
>With asynchronous transmition one fake bit can spoil several
>characters...
>
>Pawel
>                    ---------------------
>
>Sounds like fun, does'nt it ?
>
>--Johan, KC7WW
>                    
>
>

From danie.brynard@pixie.co.za  Sun Feb 11 02:45:08 1996
Received: from f15.pix.za (root@f15.pix.za [196.11.62.108]) by tapr.org (8.7.3/8.7.2) with ESMTP id CAA20615 for <hfsig@tapr.org>; Sun, 11 Feb 1996 02:44:56 -0600 (CST)
Received: from net-13.pta.pix.za (net-3.pta.pix.za [196.11.63.3]) by f15.pix.za (8.7.1/8.6.11) with SMTP id KAA18851 for <hfsig@tapr.org>; Sun, 11 Feb 1996 10:47:10 +0200
Message-Id: <199602110847.KAA18851@f15.pix.za>
X-Sender: pak03226@pixie.co.za
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 11 Feb 1996 10:44:45 +0200
To: hfsig@tapr.org
From: danie.brynard@pixie.co.za (Danie Brynard)
Subject: Re: [HFSIG:856] DSP Tools

The ALEFNULL stuff at nic.funet.fi is a good start ! Matlab is also a good
analysis tool. There is a student version out. The next step is to get a
DSP56002EVM .....73 danie zs6awk

>Hi everybody,
>I'm new to the SIG and just getting into this interesting DSP stuff.  Was
wondering if anybody has any suggestions on software design/simulation
packages for dsp designs that don't require a second mortgage on the house:-)
>I've got Math CAD and am looking at QEDesign.
>Also how about book recommendations. Best I've found so far is Marvin
Frerking's "Digital Signal Processing in Communications Systems".
>Any thoughts or referals to past threads would be appreciated. Thanks!
>
>Moe AE4JY
>mwheatle@trsystems.com
>
>

From danie.brynard@pixie.co.za  Sun Feb 11 02:45:23 1996
Received: from f15.pix.za (root@f15.pix.za [196.11.62.108]) by tapr.org (8.7.3/8.7.2) with ESMTP id CAA20627 for <hfsig@tapr.org>; Sun, 11 Feb 1996 02:45:08 -0600 (CST)
Received: from net-13.pta.pix.za (net-3.pta.pix.za [196.11.63.3]) by f15.pix.za (8.7.1/8.6.11) with SMTP id KAA18857 for <hfsig@tapr.org>; Sun, 11 Feb 1996 10:47:27 +0200
Message-Id: <199602110847.KAA18857@f15.pix.za>
X-Sender: pak03226@pixie.co.za
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 11 Feb 1996 10:45:02 +0200
To: hfsig@tapr.org
From: danie.brynard@pixie.co.za (Danie Brynard)
Subject: Re: [HFSIG:859] Re: SLOW BPSK NEWS

>What frequency on 20 are you using?
>

I can be on 14.168 SSB/CW and 14.065 SBPSK if somebody want to try slow
bpsk. A typical time suitable for me is 2000UTC. Let me know .... 73 danie
zs6awk

BRYD@KIDD.CO.ZA

From danie.brynard@pixie.co.za  Sun Feb 11 02:45:49 1996
Received: from f15.pix.za (root@f15.pix.za [196.11.62.108]) by tapr.org (8.7.3/8.7.2) with ESMTP id CAA20639 for <hfsig@tapr.org>; Sun, 11 Feb 1996 02:45:17 -0600 (CST)
Received: from net-13.pta.pix.za (net-3.pta.pix.za [196.11.63.3]) by f15.pix.za (8.7.1/8.6.11) with SMTP id KAA18860 for <hfsig@tapr.org>; Sun, 11 Feb 1996 10:47:32 +0200
Message-Id: <199602110847.KAA18860@f15.pix.za>
X-Sender: pak03226@pixie.co.za
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 11 Feb 1996 10:45:05 +0200
To: hfsig@tapr.org
From: danie.brynard@pixie.co.za (Danie Brynard)
Subject: Re: [HFSIG:860] Re: SLOW BPSK NEWS

Johan how did you determine the optimum audio level input for your SBPSK
demod ?   Danie zs6awk BRYD@KIDD.CO.ZA

>Hi Stephen,
>
>
>We are on 14.100, closeby the international CW beacon frequency. Set 
>your dial for a readout of 14.100 on LSB mode. The actual carrier is some 
>1650 Hz lower down from 14.100. Use the CW beacons as a reference for 
>propation status.
>
>The beacon is on for a few hours between about 12.00 - 20.00 UTC. I can 
>arrange to have it on for other periods as well.
>
>73's
>
>--Johan, KC7WW
>

From Hakan.Bergzen@telub.se Sun Feb 11 06:01:53 1996
Received: from terminus.inforum.telub.se (terminus.inforum.telub.se [147.13.12.199]) by tapr.org (8.7.3/8.7.2) with SMTP id GAA26187 for <hfsig@tapr.org>; Sun, 11 Feb 1996 06:01:47 -0600 (CST)
Received: from noak.vxo.telub.se by terminus.inforum.telub.se with SMTP (PP) 
          id <11381-0@terminus.inforum.telub.se>;
          Sun, 11 Feb 1996 13:01:07 +0100
Received: by noak with Microsoft Mail id <3128E503@noak>;
          Sun, 11 Feb 96 13:00:51 GMT
From: "Bergzen Hakan, KARL" <Hakan.Bergzen@telub.se>
To: HFSIG at TAPR <hfsig@tapr.org>
Subject: HF channel simulator
Date: Sun, 11 Feb 96 12:55:00 GMT
Message-ID: <3128E503@noak>
Return-Receipt-To: HABE <Hakan.Bergzen@telub.se>
Encoding: 36 TEXT
X-Mailer: Microsoft Mail V3.0
MIME-Version: 1.0
Content-Type: Text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit


Hello,

This week I participated (only passively though) in a very good  HF 
conference, or colloquium as they call it just to make it tricky to 
pronounciate and spell ;-). It was called 'HF frequency selection and 
management techniques for HF communications', and was held in London and 
arranged by the IEE.

It addresses several topics of interest to this group, e.g. the DAMSON 
northern latitude ionospheric measurement project, NATO work on developing a 
new robust waveform to handle those extreme conditions (as measured by 
DAMSON) and development of adaptive HF systems (and standardization 
thereof).

I will, however, mention two other topics of interest:

1. The next ITU frequency conference (I don't know if it really is called a 
conference) will discuss a Swedish proposal of using frequency block 
allocations on MF and HF wavelengths thus enabling truly efficient use of 
the new adaptive HF systems. (The situation today seems to be quite chaotic) 
A paper by L W Barcaly called 'A changed regulatory environment for the HF 
services' addressed this. I guess you could say that the amateur radio 
allocations are the truly first block allocations.

2. Tricia Willink of the Communications Research Centre in Ottawa presented 
their work on validating HF channel simulators being developed by both them 
and the UK Defence Research Agency. The paper is called 'Validation of HF 
channel simulators'. These were very thorough and professional tests and I 
would think it wise to consider a likewise approach if an HF channel 
simulator would be developed within this group (e.g. based on Alexander's 
simulator). Thus we could truly say that it behaves as expected.

A brief report from

Hakan  (hakan.bergzen@telub.se)

From karn@qualcomm.com Sun Feb 11 20:44:45 1996
Received: from zeus.qualcomm.com (zeus.qualcomm.com [129.46.50.42]) by tapr.org (8.7.3/8.7.2) with ESMTP id UAA11983 for <hfsig@tapr.org>; Sun, 11 Feb 1996 20:44:39 -0600 (CST)
Received: from qualcomm.com (qualcomm.com [192.35.156.11]) by zeus.qualcomm.com (8.7.3/8.7.2/1.4) with ESMTP id SAA15577 for <hfsig@tapr.org>; Sun, 11 Feb 1996 18:44:06 -0800 (PST)
Received: from laptop.qualcomm.com (laptop.ka9q.ampr.org [129.46.90.37]) by qualcomm.com  with SMTP id SAA12131 for <hfsig@tapr.org>; Sun, 11 Feb 1996 18:44:50 -0800 (PST)
Date: Sun, 11 Feb 1996 18:44:50 -0800 (PST)
Message-Id: <199602120244.SAA12131@qualcomm.com>
X-Sender: karn@servo.qualcomm.com (Unverified)
X-Mailer: Windows Eudora Pro Version 2.1.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: hfsig@tapr.org
From: Phil Karn <karn@qualcomm.com>
Subject: Re: [HFSIG:858] Re: DSP Tools

At 06:22 PM 2/8/96 -0600, you wrote:

>As for DSP development platforms.  Both TI (www.ti.com) and Motorola
>(www.motorola.com) have inexpensive DSP Starter Kits (DSK) (TI) or
>Evaluation Modules (EVM) (Motorola).  The TI C5X DSK (p/n TMDS3200051) costs
>$99.00 and the Motorola EVM560002 costs $149.00.  I own the later and have
>the former on order.

Don't forget that you can do serious DSP on general purpose computers without
a DSP board. Pentiums and the faster 486s rival many dedicated DSPs, especially
on floating point computations.

Phil

From danie.brynard@pixie.co.za  Sun Feb 11 23:07:04 1996
Received: from f15.pix.za (root@f15.pix.za [196.11.62.108]) by tapr.org (8.7.3/8.7.2) with ESMTP id XAA17920 for <hfsig@tapr.org>; Sun, 11 Feb 1996 23:06:59 -0600 (CST)
Received: from net-14.pta.pix.za (net-14.pta.pix.za [196.11.63.14]) by f15.pix.za (8.7.1/8.6.11) with SMTP id HAA14738 for <hfsig@tapr.org>; Mon, 12 Feb 1996 07:09:25 +0200
Message-Id: <199602120509.HAA14738@f15.pix.za>
X-Sender: pak03226@pixie.co.za
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 12 Feb 1996 07:06:56 +0200
To: hfsig@tapr.org
From: danie.brynard@pixie.co.za (Danie Brynard)
Subject: Re: [HFSIG:868] Re: DSP Tools


>Don't forget that you can do serious DSP on general purpose computers without
>a DSP board. Pentiums and the faster 486s rival many dedicated DSPs, especially
>on floating point computations.
>

Sounds exciting Phil. What software is available so far for the satellites ?

73 Danie

From hstr@gil.com.au Mon Feb 12 07:36:08 1996
Received: from iccu6.ipswich.gil.com.au (iccu6.ipswich.gil.com.au [203.1.75.10]) by tapr.org (8.7.3/8.7.2) with ESMTP id HAA11464 for <hfsig@tapr.org>; Mon, 12 Feb 1996 07:36:04 -0600 (CST)
Received: from cs5p4.ipswich.gil.com.au (cs5p4.ipswich.gil.com.au [203.1.75.33]) by iccu6.ipswich.gil.com.au with SMTP id IAA29492
  (8.6.12/IDA-1.6 for <hfsig@tapr.org>); Mon, 12 Feb 1996 08:35:28 -0500
Message-ID: <199602121335.IAA29492@iccu6.ipswich.gil.com.au>
Comments: Authenticated sender is <hstr@mail.ipswich.gil.com.au>
From: "Helmut Strickner" <hstr@gil.com.au>
To: hfsig@tapr.org
Date: Mon, 12 Feb 1996 23:35:46 +1000
Subject: Re: [HFSIG:853] SLOW BPSK NEWS
Priority: normal
X-mailer: Pegasus Mail for Windows (v2.23)

>
Hello Johan, Pawel and all

good news about the slow BPSK. I would be interested in participating 
in the experiments. Unfortunately the 10 hour time difference between 
VK land and stateside/Europe is a bit of a problem with listening to 
the beacon (also the propagation). Johan I wonder if you could have the
beacon on weekends when there is propagation to VK4?
The other question is regarding the modem software, I have not seen
it as yet, probably Pawel distributed it only to a small group.
Perhaps I could get a copy too, I would be able to put out a beacon
from my QTH during some periods of propagation if there is any
interest.

Helmut VK4STR


 Hi all,
> 
> Some exciting news that we want to share. 
> 
> Pawel, SP9VRC is presently at CERN, Switzerland, and have been patiently 
> listening for my (KC7WW, Monroe, Oregon) slow speed BPSK transmissions on 
> 20 meters. My setup consists of a DSP56002EVM running Pawel's SLOWBPSK 
> program, an an ICOM 751 on LSB mode, RF output is 10W to a Butternut 
> vertical. 
> 
> For the first time; yesterday looked like Pawel got something - not yet 
> confirming callsigns, but that is only a matter of time. Here is what he 
> e-mailed me:
> 
>                      ----------------------------
> Well, this time something did work. Today at 16:20 UTC I got a long lock
> (I didn't need to wait long for it) and then in the garbage characters
> I could clearly see CQ (with capital letters) being sent at least four 
> times.
> They were not in a row but at a distance of some 60-80 characters.
> I could see as well the space before or after them.
> 
> I was listenning with the TS-440 and I used the narrow filter
> (I didn't try the wide filter at that time). I was not able to
> hear any audible signal by ear.
> However, I noticed there is some weak but regular CW being sent on this
> or close frequency - it that you ?
> 
> I left the setup running and the output is being recorded on a file.
> I will send you the file later.
> I have made a schedule at 20:00 UTC on 14.180 USB voice with Danie
> every day this week and weekend.
> 
> I'm sure I would capture more text if we had the FEC and good block-sync.
> With asynchronous transmition one fake bit can spoil several
> characters...
> 
> Pawel
>                     ---------------------
> 
> Sounds like fun, does'nt it ?
> 
> --Johan, KC7WW
>                     
> 
> 
> 

From dona@tridelta.com  Mon Feb 12 08:43:35 1996
Received: from wariat.wariat.org (uucp@wariat.wariat.org [192.147.147.1]) by tapr.org (8.7.3/8.7.2) with ESMTP id IAA14638 for <hfsig@tapr.org>; Mon, 12 Feb 1996 08:43:33 -0600 (CST)
Received: from tridelta.com (uucp@localhost) by wariat.wariat.org (8.6.12/8.6.9) with UUCP id JAA02850 for hfsig@tapr.org; Mon, 12 Feb 1996 09:43:31 -0500
Received: from sparcy.tridelta.com (sparcy [192.160.168.222]) by tdi3.tridelta.com (8.6.9/8.6.9) with ESMTP id JAA12383 for <hfsig@tapr.org>; Mon, 12 Feb 1996 09:15:50 -0500
Received: from donapc.tridelta.com (donapc.tridelta.com [192.160.168.70]) by sparcy.tridelta.com (8.7.1/8.7.1) with SMTP id JAA24420 for <hfsig@tapr.org>; Mon, 12 Feb 1996 09:14:56 -0500 (EST)
Date: Mon, 12 Feb 1996 09:14:56 -0500 (EST)
Message-Id: <199602121414.JAA24420@sparcy.tridelta.com>
X-Sender: dona@sparcy
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: hfsig@tapr.org
From: dona@tridelta.com (Don Adams)
Subject: Re: [HFSIG:866] Re: SLOW BPSK NEWS

Where's the spec's on the format Ur using for this slow bsk?
(I've read most of the archives but I must have missed it)

                over and out  don   WA8QZZ

From FORRERJ@frl.orst.edu Mon Feb 12 10:52:04 1996
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by tapr.org (8.7.3/8.7.3/1.8) with SMTP id KAA20861 for <hfsig@tapr.org>; Mon, 12 Feb 1996 10:51:59 -0600 (CST)
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.118.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with ESMTP id IAA12272 for <hfsig@tapr.org>; Mon, 12 Feb 1996 08:48:45 -0800
Received: from FRL/SpoolDir by frl.orst.edu (Mercury 1.21);
    12 Feb 96 08:59:10 PST8PDT
Received: from SpoolDir by FRL (Mercury 1.21); 12 Feb 96 08:59:07 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Mon, 12 Feb 1996 08:59:04 -0800
Subject:       Re: [HFSIG:870] Re: SLOW BPSK NEWS
Priority: normal
X-mailer: Pegasus Mail v3.22
Message-ID: <24F41D42498@frl.orst.edu>

Hello Helmuth,

I would be happy to put the beacon on for longer/different periods and that 
would be nice to get your participating in listening. Which times would you 
suggest trying? 

This weekend I heard the JA CW beacon in the late afternoons, so I 
suppose there is propagation towards the east.

When I get home tonight I'll forward you my copy of SLOWBPSK. I am in the 
process of putting together an updated collection of items for the EVM 
for use on HF - that will probably be ready in the near future. This 
includes some new stuff for the 66/80 MHz EVM. I will ask Pawel whether it 
is OK for me to include his latest code. These are the PSK 
terrestrial/satellite modems and the SLOWBPSK. I also have had excellent 
results using his FAX/SSTV DSP modem. 

Till later,

--Johan, KC7WW

From FORRERJ@frl.orst.edu Mon Feb 12 11:01:11 1996
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by tapr.org (8.7.3/8.7.3/1.8) with SMTP id LAA21212 for <hfsig@tapr.org>; Mon, 12 Feb 1996 11:01:08 -0600 (CST)
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.118.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with ESMTP id IAA12322 for <hfsig@tapr.org>; Mon, 12 Feb 1996 08:57:53 -0800
Received: from FRL/SpoolDir by frl.orst.edu (Mercury 1.21);
    12 Feb 96 09:08:17 PST8PDT
Received: from SpoolDir by FRL (Mercury 1.21); 12 Feb 96 09:08:02 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Mon, 12 Feb 1996 09:07:57 -0800
Subject:       Re: [HFSIG:871] Re: SLOW BPSK NEWS
Priority: normal
X-mailer: Pegasus Mail v3.22
Message-ID: <24F67D9386A@frl.orst.edu>

Don,

The SLOWBPSK format was described in several of Pawel's (SP9VRC) 
postings. There was some discussion about the use and implementation of 
"raised cosine" pulse shaping - if you could locate that, you will see what 
it's about.

But just to elaborate a bit if I may, it is BPSK at 30 bps. The symbol set 
is straight ASCII. Nothing fancy as far as this is concerned. Wafeform 
shaping and a good demodulator makes the difference.

Hope this helps. Perhaps Pawel want to elaborate further. How about that 
Pawel?

--Johan

From alanb@polecat.sr.hp.com Mon Feb 12 11:18:18 1996
Received: from hp.com (hp.com [15.255.152.4]) by tapr.org (8.7.3/8.7.3/1.8) with ESMTP id LAA22031 for <hfsig@tapr.org>; Mon, 12 Feb 1996 11:18:11 -0600 (CST)
Received: from srmail.sr.hp.com by hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA011785476; Mon, 12 Feb 1996 09:17:59 -0800
Received: from polecat.sr.hp.com by srmail.sr.hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA056465471; Mon, 12 Feb 1996 09:17:52 -0800
Received: by polecat.sr.hp.com
	(1.37.109.16/15.5+ECS 3.3) id AA000935471; Mon, 12 Feb 1996 09:17:51 -0800
From: Alan Bloom <alanb@polecat.sr.hp.com>
Message-Id: <199602121717.AA000935471@polecat.sr.hp.com>
Subject: DSP processors
To: hfsig@tapr.org
Date: Mon, 12 Feb 1996 09:17:50 -0800 (PST)
X-Mailer: ELM [version 2.4 PL21]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Phil Karn <karn@qualcomm.com> wrote:

>Don't forget that you can do serious DSP on general purpose computers without
>a DSP board. Pentiums and the faster 486s rival many dedicated DSPs, especially
>on floating point computations.

And for non-real-time processing (or for simple low-bandwidth applications)
you can make do with something a lot less powerful than a Pentium.

Al N1AL

From FORRERJ@frl.orst.edu Mon Feb 12 11:19:13 1996
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by tapr.org (8.7.3/8.7.3/1.8) with SMTP id LAA22380 for <HFSIG@TAPR.ORG>; Mon, 12 Feb 1996 11:19:03 -0600 (CST)
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.118.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with ESMTP id JAA12457 for <HFSIG@TAPR.ORG>; Mon, 12 Feb 1996 09:15:46 -0800
Received: from FRL/SpoolDir by frl.orst.edu (Mercury 1.21);
    12 Feb 96 09:26:11 PST8PDT
Received: from SpoolDir by FRL (Mercury 1.21); 12 Feb 96 09:26:00 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: HFSIG@tapr.org
Date:          Mon, 12 Feb 1996 09:25:55 -0800
Subject:       Help with EZKIT
Priority: normal
X-mailer: Pegasus Mail v3.22
Message-ID: <24FB4927CC6@frl.orst.edu>

Hi,

I wonder if there is some kind soul that could help me get my EZKITLITE 
going - My second software disk is bad. As far as I can tell, all I need 
is the file "EZKITAPP.EXE" and it is called "EZKITAPP.EX$" on the disk.

I would greatly appreciate it if someone can e-mail me the file. It is some 
170K, otherwise I have to go the long route to get it replaced.

Thanks much.

--Johan 

From cbuttsch@slonet.org Mon Feb 12 12:37:19 1996
Received: from biggulp.callamer.com (cbuttsch@biggulp.callamer.com [199.74.141.2]) by tapr.org (8.7.3/8.7.3/1.8) with SMTP id MAA26409; Mon, 12 Feb 1996 12:37:15 -0600 (CST)
Received: (from cbuttsch@localhost) by biggulp.callamer.com (8.6.12/8.6.9-callamer-rdw080995) id KAA19694; Mon, 12 Feb 1996 10:35:56 -0800
Date: Mon, 12 Feb 1996 10:35:56 -0800 (PST)
From: Clifford Buttschardt <cbuttsch@slonet.org>
To: Johan Forrer <FORRERJ@frl.orst.edu>
cc: hfsig@tapr.org, ss@tapr.org
Subject: Re: [HFSIG:872] Re: SLOW BPSK NEWS
In-Reply-To: <24F41D42498@frl.orst.edu>
Message-ID: <Pine.OSF.3.91.960212102003.1931D-100000@biggulp.callamer.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Johan.  Many thanks for your encouragement regarding the slow speed 
BPSK that we both are doing.  I was most interested to see where your are 
using 30 bps ASCII!  Since I had no clue, it is refreshing to know this.  
We are using ten bps ASCII also with seven data bits and two stop bits.  
This produces one character persecond.  The software is entirely done, 
and in fact improved daily.  We started out with 12 samples per bit and 
now are up to 20----the maximum that a 486 computer can analyze real 
time.  The system is about to be changed to what is called PSKL which 
stands for Phase Shift Keying Lattice code.  Where the 7 bit code and a 
two to the seventh or 128 possible pattern, PSKL proposes to transmit a 16 
bit frame for each character instead of ten.  Here is where things differ 
from anything normal.  128 characters have to be selected.  Finally Bill 
DeCarle came up with 128 codewords that differ from each other by at 
least six bit positions!!  After all this is done then the computer 
selects the one character that has the smallest number of altered bits.
     Now before I scare everyone off with all this, realize that the work 
done so far is ORDINARY ASCII----just as you are using.  The PSKL is 
simply something we are doing for future evaluation.
     Maybe now it becomes more apparent why I have no patience fooling 
around with a silly bulletin board system that will not work for me!!
Cliff Buttschardt   W6HDO

From karn@qualcomm.com Mon Feb 12 17:42:32 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org (8.7.3/8.7.3/1.8) with ESMTP id RAA09101 for <hfsig@tapr.org>; Mon, 12 Feb 1996 17:42:29 -0600 (CST)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.3/8.7.2/1.4) id PAA17640; Mon, 12 Feb 1996 15:41:57 -0800 (PST)
Date: Mon, 12 Feb 1996 15:41:57 -0800 (PST)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199602122341.PAA17640@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <199602120509.HAA14738@f15.pix.za> (danie.brynard@pixie.co.za)
Subject: Re: [HFSIG:869] Re: DSP Tools

>Sounds exciting Phil. What software is available so far for the satellites ?

I haven't written anything yet. I'm working on a m-ary FSK scheme that's
designed primarily for HF. Because it has pretty stringent frequency
stability requirements, I doubt it will work well on satellite channels.

Phil

From FORRERJ@frl.orst.edu Mon Feb 12 18:07:00 1996
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by tapr.org (8.7.3/8.7.3/1.8) with SMTP id SAA10285 for <HFSIG@TAPR.ORG>; Mon, 12 Feb 1996 18:06:58 -0600 (CST)
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.118.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with ESMTP id QAA15003 for <HFSIG@TAPR.ORG>; Mon, 12 Feb 1996 16:03:43 -0800
Received: from FRL/SpoolDir by frl.orst.edu (Mercury 1.21);
    12 Feb 96 16:14:08 PST8PDT
Received: from SpoolDir by FRL (Mercury 1.21); 12 Feb 96 16:13:41 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: HFSIG@tapr.org
Date:          Mon, 12 Feb 1996 16:13:32 -0800
Subject:       Thanks for help on EZKITAPP
Priority: normal
X-mailer: Pegasus Mail v3.22
Message-ID: <25680386673@frl.orst.edu>

Hi,

Thanks for all the help with obtaining a good copy of the EZKITLITE
file. Marv was kind enough to help me out.

73's

--Johan, KC7WW

From sadowskp@jcsar.nellis.af.mil Mon Feb 12 19:47:14 1996
Received: from bncc.nellis.af.mil (bncc.nellis.af.mil [132.58.120.19]) by tapr.org (8.7.3/8.7.3/1.8) with SMTP id TAA13906 for <hfsig@tapr.org>; Mon, 12 Feb 1996 19:47:11 -0600 (CST)
Received: from mailgtwy.nellis.af.mil by bncc.nellis.af.mil with SMTP
	(1.38.193.4/16.2) id AA27742; Mon, 12 Feb 1996 17:40:00 -0800
Received: by mailgtwy.nellis.af.mil with Microsoft Mail
	id <311FCF59@mailgtwy.nellis.af.mil>; Mon, 12 Feb 96 17:38:01 cst
From: "Sadowski,P O4 USAF JCSAR/EDD" <sadowskp@jcsar.nellis.af.mil>
To: hfsig <hfsig@tapr.org>
Subject: RE: [HFSIG:853] SLOW BPSK NEWS
Date: Wed, 07 Feb 96 11:12:00 cst
Message-Id: <311FCF59@mailgtwy.nellis.af.mil>
Encoding: 60 TEXT
X-Mailer: Microsoft Mail V3.0


CONGRATS Pawel and Johan... keep up the good work... especially the
FEC to make it more error free....

BTW... I understand the DSP eval board you are using has been upgraded
by Motorola to a faster version 50MHz to 80MHz... any impact???

ALOHA
AL  AH6LS
 ----------
From: hfsig
To: hfsig
Subject: [HFSIG:853] SLOW BPSK NEWS
Date: Wednesday, February 07, 1996 11:50AM

Hi all,

Some exciting news that we want to share.

Pawel, SP9VRC is presently at CERN, Switzerland, and have been patiently
listening for my (KC7WW, Monroe, Oregon) slow speed BPSK transmissions on
20 meters. My setup consists of a DSP56002EVM running Pawel's SLOWBPSK
program, an an ICOM 751 on LSB mode, RF output is 10W to a Butternut
vertical.

For the first time; yesterday looked like Pawel got something - not yet
confirming callsigns, but that is only a matter of time. Here is what he
e-mailed me:

                     ----------------------------
Well, this time something did work. Today at 16:20 UTC I got a long lock
(I didn't need to wait long for it) and then in the garbage characters
I could clearly see CQ (with capital letters) being sent at least four
times.
They were not in a row but at a distance of some 60-80 characters.
I could see as well the space before or after them.

I was listenning with the TS-440 and I used the narrow filter
(I didn't try the wide filter at that time). I was not able to
hear any audible signal by ear.
However, I noticed there is some weak but regular CW being sent on this
or close frequency - it that you ?

I left the setup running and the output is being recorded on a file.
I will send you the file later.
I have made a schedule at 20:00 UTC on 14.180 USB voice with Danie
every day this week and weekend.

I'm sure I would capture more text if we had the FEC and good block-sync.
With asynchronous transmition one fake bit can spoil several
characters...

Pawel
                    ---------------------

Sounds like fun, does'nt it ?

 --Johan, KC7WW


From forrerj@ucs.orst.edu  Tue Feb 13 01:41:07 1996
Received: from ucs.orst.edu (root@UCS.ORST.EDU [128.193.4.5]) by tapr.org (8.7.3/8.7.3/1.8) with SMTP id BAA04816 for <hfsig@tapr.org>; Tue, 13 Feb 1996 01:41:05 -0600 (CST)
Received: from p06.t0.monrotel.com by ucs.orst.edu; (5.65v3.2/1.1.8.2/24Sep94-1201PM)
	id AA29098; Mon, 12 Feb 1996 23:40:56 -0800
Message-Id: <9602130740.AA29098@ucs.orst.edu>
X-Sender: forrerj@ucs.orst.edu
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 12 Feb 1996 23:44:58 -0800
To: hfsig@tapr.org
From: forrerj@ucs.orst.edu (Johan Forrer)
Subject: Re: [HFSIG:879] RE: SLOW BPSK NEWS

Hi Al,

>
>CONGRATS Pawel and Johan... keep up the good work... especially the
>FEC to make it more error free....

Well, we are not sure that we actually made contact. We will know for sure
one day when we see the callsigns in print. Anyway we are still trying.

Yes - FEC could make the difference. A good sync vector is probably needed
as well, and with the low signals, probably a lower the symbol rate as well.
But its a good start.

 
>
>BTW... I understand the DSP eval board you are using has been upgraded
>by Motorola to a faster version 50MHz to 80MHz... any impact???

I have gotten one of the new 66 MHz units - actually it is now the standard.
It appears to run at 80 MHz, at least the programs I tried seem to run with
no apparent problems. This is the unit that is running the beacon test -
appears to be quite stable.

--Johan

From JALOCHA@vxcern.cern.ch Tue Feb 13 04:33:37 1996
Received: from vscrna.cern.ch (vscrna.cern.ch [137.138.28.123]) by tapr.org (8.7.3/8.7.3/1.8) with SMTP id EAA10212 for <hfsig@tapr.org>; Tue, 13 Feb 1996 04:33:35 -0600 (CST)
Date: Tue, 13 Feb 1996 11:32:43 +0100 (CET)
From: Pawel Jalocha <JALOCHA@vxcern.cern.ch>
To: hfsig@tapr.org
Message-Id: <960213113243.21b2422c@vxcern.cern.ch>
Subject: SLOWBPSK data format

Hello to all,

The SLOWBPSK.ASM makes an audio signal at 1650 Hz (defineable) which is
DBPSK modulated at 31.25 bits/sec. The 31.25 comes from the 8000 Hz
sampling which I divide by 256.

Bit format: phase transition => logical 1
	    no phase transition => logical 0

Data encoding: asynchronous-like 7-bit ASCII:
start-bit + seven data bits + stop bit.
But note that the bit stream is still synchronous !

The receiver when not locked slowly sweeps a defineable audio range
(like 1600-1700 Hz at 3 Hz/sec) and when locked it stops sweeping
and decodes the data while still tracking the carrier.

Obviously I am thinking of adding a FEC... my major problem
is how to organize the blocks and how to synchronize to these
at the receiver.

Pawel

From chbrain@dircon.co.uk  Tue Feb 13 12:53:14 1996
Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by tapr.org (8.7.3/8.7.3/1.8) with SMTP id MAA26640 for <hfsig@tapr.org>; Tue, 13 Feb 1996 12:53:04 -0600 (CST)
Received: by felix.dircon.co.uk id AA19557
  (5.67b/IDA-1.5 for <hfsig@tapr.org>); Tue, 13 Feb 1996 18:52:40 GMT
Message-Id: <199602131852.AA19557@felix.dircon.co.uk>
Received: from gw2-101.pool.dircon.co.uk(194.112.35.101) by amnesiac via smap (V1.3)
	id sma019526; Tue Feb 13 18:52:08 1996
X-Sender: chbrain@popmail.dircon.co.uk
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 13 Feb 1996 18:22:59 +0000
To: hfsig@tapr.org
From: chbrain@dircon.co.uk (Charles Brain)
Subject: Re: 56002 EVM

Hello Johan,
>I have gotten one of the new 66 MHz units - actually it is now the standard.
>It appears to run at 80 MHz, at least the programs I tried seem to run with
>no apparent problems. This is the unit that is running the beacon test -
>appears to be quite stable.
>
>--Johan
>
>
Do you have the part number for the EVM board. Is the 56002 a superset 
of the 56000 ?

73 Charles G4GUO

From forrerj@ucs.orst.edu Tue Feb 13 15:04:19 1996
Received: from ucs.orst.edu (forrerj@UCS.ORST.EDU [128.193.4.5]) by tapr.org (8.7.3/8.7.3/1.8) with SMTP id PAA02043 for <hfsig@tapr.org>; Tue, 13 Feb 1996 15:04:16 -0600 (CST)
Received: by ucs.orst.edu; (5.65v3.2/1.1.8.2/24Sep94-1201PM)
	id AA18768; Tue, 13 Feb 1996 13:04:05 -0800
Date: Tue, 13 Feb 1996 13:04:04 -0800 (PST)
From: Johan Forrer <forrerj@ucs.orst.edu>
To: hfsig@tapr.org
Subject: Re: [HFSIG:882] Re: 56002 EVM
In-Reply-To: <199602131852.AA19557@felix.dircon.co.uk>
Message-Id: <Pine.OSF.3.91.960213125531.6810A-100000@ucs.orst.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Charles,

I don't want to sound like a Moto salesman - just my personal experiences 
for what it's worth.

On Tue, 13 Feb 1996, Charles Brain wrote:

> Hello Johan,
> >I have gotten one of the new 66 MHz units - actually it is now the standard.
> >It appears to run at 80 MHz, at least the programs I tried seem to run with
> >no apparent problems. This is the unit that is running the beacon test -
> >appears to be quite stable.
> >
> >--Johan
> >
> >
> Do you have the part number for the EVM board. Is the 56002 a superset 
> of the 56000 ?
> 
> 73 Charles G4GUO
> 
> 

The part is still called the DSP56002EVM, but be sure to ask to make 
sure that the DSP has the "66" stamped on it. That is how you would know. 

The 56002 is part of the 56000 family and there are many similarities 
shared by products in the family. The 56002 uses a different die 
than the 56001, the new process giving it the higher clocking capability. 
I would not call it a "superset" instruction set, but rather a few extra 
bits in some of the special registers that used to be labelled "reserved".

Does this help?

--Johan

From s56a@s55tcp.ampr.org Tue Feb 13 15:42:19 1996
Received: from s55tcp.ampr.org (radio.kud-fp.si [193.2.132.80]) by tapr.org (8.7.3/8.7.3/1.8) with SMTP id PAA03290 for <hfsig@tapr.org>; Tue, 13 Feb 1996 15:42:16 -0600 (CST)
Date: Tue, 13 Feb 96 21:38:15 EST
Message-Id: <139129@s55tcp.ampr.org>
From: Marijan Miletic <s56a@s55tcp.ampr.org>
Reply-To: S56A@s55tcp.ampr.org
To: hfsig@tapr.org
Subject: Re: [HFSIG:882] Re: 56002 EVM
In-Reply-To: your message of Tue Feb 13 12:55:46 1996
             <199602131852.AA19557@felix.dircon.co.uk>

From chbrain@dircon.co.uk  Tue Feb 13 15:52:43 1996
Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by tapr.org (8.7.3/8.7.3/1.8) with SMTP id PAA03934 for <hfsig@tapr.org>; Tue, 13 Feb 1996 15:52:09 -0600 (CST)
Received: by felix.dircon.co.uk id AA00748
  (5.67b/IDA-1.5 for <hfsig@tapr.org>); Tue, 13 Feb 1996 21:51:49 GMT
Message-Id: <199602132151.AA00748@felix.dircon.co.uk>
Received: from gw2-147.pool.dircon.co.uk(194.112.35.147) by amnesiac via smap (V1.3)
	id sma000733; Tue Feb 13 21:51:23 1996
X-Sender: chbrain@popmail.dircon.co.uk
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 13 Feb 1996 21:22:18 +0000
To: hfsig@tapr.org
From: chbrain@dircon.co.uk (Charles Brain)
Subject: Re: [HFSIG:883] Re: 56002 EVM

>
>The part is still called the DSP56002EVM, but be sure to ask to make 
>sure that the DSP has the "66" stamped on it. That is how you would know. 
>                                        ^^
Hi Johan,
Yes that helps, Its difficult to explain to people at the other end of the
phone the differences in these things.

I guess I'll get one of these as it seems to be the platform of choice for
HFSIG, better than the TI DSK. I only asked about the superset !? as I 
have a 56000 assembler manual upstairs so I can look at that.

Tnx again

Charles G4GUO 

From FORRERJ@frl.orst.edu Wed Feb 14 11:26:50 1996
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by tapr.org (8.7.3/8.7.3/1.8) with SMTP id LAA21924 for <hfsig@tapr.org>; Wed, 14 Feb 1996 11:26:47 -0600 (CST)
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.118.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with ESMTP id JAA22410 for <hfsig@tapr.org>; Wed, 14 Feb 1996 09:23:25 -0800
Received: from FRL/SpoolDir by frl.orst.edu (Mercury 1.21);
    14 Feb 96 09:33:54 PST8PDT
Received: from SpoolDir by FRL (Mercury 1.21); 14 Feb 96 09:33:29 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Wed, 14 Feb 1996 09:33:23 -0800
Subject:       New EVM library available
Priority: normal
X-mailer: Pegasus Mail v3.22
Message-ID: <27FD5DB54C8@frl.orst.edu>

Hi,

I have updated the DSP56002EVM software library with the more recent 
versions of code. It is now available for downloading as 
EVM56K2A.TXT and EVM56K2A.ZIP from the tapr/SIG/hfsig/upload area.

As usual, this is the full source code to everything that was contributed.

Thank you to those that generously contributed their fine efforts - we 
are most appreciative.

Enjoy.

--Johan, KC7WW

From FORRERJ@frl.orst.edu Wed Feb 14 16:00:11 1996
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by tapr.org (8.7.3/8.7.3/1.8) with SMTP id QAA02810 for <HFSIG@TAPR.ORG>; Wed, 14 Feb 1996 16:00:08 -0600 (CST)
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.118.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with ESMTP id NAA23691 for <HFSIG@TAPR.ORG>; Wed, 14 Feb 1996 13:56:45 -0800
Received: from FRL/SpoolDir by frl.orst.edu (Mercury 1.21);
    14 Feb 96 14:07:14 PST8PDT
Received: from SpoolDir by FRL (Mercury 1.21); 14 Feb 96 14:07:07 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: HFSIG@tapr.org
Date:          Wed, 14 Feb 1996 14:06:58 -0800
Subject:       Sync Vectors for HF Digital
Priority: normal
X-mailer: Pegasus Mail v3.22
Message-ID: <28465840951@frl.orst.edu>

Hi all,

I am looking for ideas on a suitable sync. vector for use on HF, 
something better than what is currently used on Packet or Pactor for 
instance.

In this regard, AX.25 Packet use "7Eh", Pactor uses a "55h/AAh" 
pattern, the so-called "header byte." BTW not really for frame sync 
purposes - that is done by brute force search for a valid CRC over a 
block of raw bits. 

Phil suggests a 63-bit PN sequence in his "Toward New Link Layer Protocols" 
where a 13/64 match is considered a hit. That is some 8 bytes long - is 
this the kind of header that should be used.

Any suggestions or ideas would be welcome.

Thanks in advance.

--Johan, KC7WW

From chbrain@dircon.co.uk  Thu Feb 15 04:14:01 1996
Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by tapr.org (8.7.3/8.7.3/1.8) with SMTP id EAA05297 for <hfsig@tapr.org>; Thu, 15 Feb 1996 04:13:55 -0600 (CST)
Received: by felix.dircon.co.uk id AA01304
  (5.67b/IDA-1.5 for <hfsig@tapr.org>); Thu, 15 Feb 1996 10:12:47 GMT
Message-Id: <199602151012.AA01304@felix.dircon.co.uk>
Received: from gw2-132.pool.dircon.co.uk(194.112.35.132) by amnesiac via smap (V1.3)
	id sma005951; Thu Feb 15 07:51:53 1996
X-Sender: chbrain@popmail.dircon.co.uk
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 15 Feb 1996 07:22:27 +0000
To: hfsig@tapr.org
From: chbrain@dircon.co.uk (Charles Brain)
Subject: Re: [HFSIG:887] Sync Vectors for HF Digital

>Hi all,
>
>I am looking for ideas on a suitable sync. vector for use on HF, 
>something better than what is currently used on Packet or Pactor for 
>instance.
>
>--Johan, KC7WW
>
>
Hello Johan,
You could use Barker codes, the HF modem we have at work use them for
sync. These codes are described on page 10-61 of "The ARRL Spread
Spectrum Source Book". In fact appendix B of that book has a whole 
section on synch after clock recovery.

73 Charles

From k4gvo@america.net Thu Feb 15 04:42:08 1996
Received: from america.net (atl1.america.net [199.170.121.2]) by tapr.org (8.7.3/8.7.3/1.8) with SMTP id EAA06195 for <hfsig@tapr.org>; Thu, 15 Feb 1996 04:42:06 -0600 (CST)
Message-Id: <199602151042.EAA06195@tapr.org>
Received: from k4gvo (pm1-14.america.net [199.170.121.114]) by america.net (8.6.10/8.6.9) with SMTP id FAA09417 for <hfsig@tapr.org>; Thu, 15 Feb 1996 05:45:05 -0500
Sender: <k4gvo@atl1.america.net>
From: "Jim Lynch" <k4gvo@america.net>
To: hfsig@tapr.org
Date:          Thu, 15 Feb 1996 05:40:49 +0000
Subject:       Re: [HFSIG:887] Sync Vectors for HF Digital
Reply-to: k4gvo@america.net
Priority: normal
X-mailer: Pegasus Mail/Windows (v1.22)

> Date:          Wed, 14 Feb 1996 16:17:59 -0600 (CST)
> Reply-to:      hfsig@tapr.org
> From:          "Johan Forrer" <FORRERJ@frl.orst.edu>
> To:            hfsig@tapr.org
> Subject:       [HFSIG:887] Sync Vectors for HF Digital

> Hi all,
> 
> I am looking for ideas on a suitable sync. vector for use on HF, 
> something better than what is currently used on Packet or Pactor for 
> instance.
> 
> In this regard, AX.25 Packet use "7Eh", Pactor uses a "55h/AAh" 
> pattern, the so-called "header byte." BTW not really for frame sync 
> purposes - that is done by brute force search for a valid CRC over a 
> block of raw bits. 
> 
> Phil suggests a 63-bit PN sequence in his "Toward New Link Layer Protocols" 
> where a 13/64 match is considered a hit. That is some 8 bytes long - is 
> this the kind of header that should be used.
> 
> Any suggestions or ideas would be welcome.
> 
> Thanks in advance.
> 
> --Johan, KC7WW
Hi, Johan.

Would it make sense to have the header adaptive?  I like Phil's idea, 
but it might be a waste of time for very good connections.  How about
a one byte header for great connections, no retries, a 4 byte header 
for fair connections and an  8 byte for the I-don't-hear-anyone 
connections.  

Jim.
> 
> 
Jim Lynch           Fayetteville, GA       K4GVO
'86 GL1200I         k4gvo@america.net      44.36.34.20

From dona@tridelta.com  Thu Feb 15 07:43:32 1996
Received: from wariat.wariat.org (uucp@wariat.wariat.org [192.147.147.1]) by tapr.org (8.7.3/8.7.3/1.8) with ESMTP id HAA11371 for <hfsig@tapr.org>; Thu, 15 Feb 1996 07:43:29 -0600 (CST)
Received: from tridelta.com (uucp@localhost) by wariat.wariat.org (8.6.12/8.6.9) with UUCP id IAA21378 for hfsig@tapr.org; Thu, 15 Feb 1996 08:43:22 -0500
Received: from sparcy.tridelta.com (sparcy [192.160.168.222]) by tdi3.tridelta.com (8.6.9/8.6.9) with ESMTP id IAA07193 for <hfsig@tapr.org>; Thu, 15 Feb 1996 08:36:16 -0500
Received: from donapc.tridelta.com (donapc.tridelta.com [192.160.168.70]) by sparcy.tridelta.com (8.7.1/8.7.1) with SMTP id IAA28704 for <hfsig@tapr.org>; Thu, 15 Feb 1996 08:35:28 -0500 (EST)
Date: Thu, 15 Feb 1996 08:35:28 -0500 (EST)
Message-Id: <199602151335.IAA28704@sparcy.tridelta.com>
X-Sender: dona@sparcy
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: hfsig@tapr.org
From: dona@tridelta.com (Don Adams)
Subject: Re: [HFSIG:889] Re: Sync Vectors for HF Digital


>
>Would it make sense to have the header adaptive?  I like Phil's idea, 
>but it might be a waste of time for very good connections.  How about
>a one byte header for great connections, no retries, a 4 byte header 
>for fair connections and an  8 byte for the I-don't-hear-anyone 
>connections.  
>
>Jim.
>> 
>> 
>Jim Lynch           Fayetteville, GA       K4GVO
>'86 GL1200I         k4gvo@america.net      44.36.34.20
>
>
In the old IBM bisync world, the sync was esablished as the first non sync
character
afer a string >1 sync characacters.    This idea is simple and would allow U to 
integrate (corrolate) over many (8 or 4 or what ever) when establishing the
contact
and then shorten it as need be for  appropiate signal quality. The sync
char, itself,
(I think it was a control V or there abouts), had good corrolation qualities
of its own.

From forrerj@ucs.orst.edu Thu Feb 15 11:06:59 1996
Received: from ucs.orst.edu (forrerj@UCS.ORST.EDU [128.193.4.5]) by tapr.org (8.7.3/8.7.3/1.8) with SMTP id LAA19372 for <hfsig@tapr.org>; Thu, 15 Feb 1996 11:06:52 -0600 (CST)
Received: by ucs.orst.edu; (5.65v3.2/1.1.8.2/24Sep94-1201PM)
	id AA25065; Thu, 15 Feb 1996 09:06:46 -0800
Date: Thu, 15 Feb 1996 09:06:46 -0800 (PST)
From: Johan Forrer <forrerj@ucs.orst.edu>
To: hfsig@tapr.org
Subject: Re: [HFSIG:888] Re: Sync Vectors for HF Digital
In-Reply-To: <199602151012.AA01304@felix.dircon.co.uk>
Message-Id: <Pine.OSF.3.91.960215085929.31390C-100000@ucs.orst.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Charles,

On Thu, 15 Feb 1996, Charles Brain wrote:


> Hello Johan,
> You could use Barker codes, the HF modem we have at work use them for
> sync. These codes are described on page 10-61 of "The ARRL Spread
> Spectrum Source Book". In fact appendix B of that book has a whole 
> section on synch after clock recovery.
> 
> 73 Charles
> 
> 

I have been meaning to buy that book - this weekend at the swap I'll get 
it. Thanks for the pointer.

Last night I did a bit of reading up and see the Barker sequence has very 
good properties. The main issue is the autocorrelation function that give 
a high only at the perfect sync position and next to nil when offset by 
any other amount. The book also stated that the right PN sequence may be  
as good as a Barker sequence in many situations. The maximum length 
known Barker sequence is only 13 bits long.

Thanks to Kok Chen that also pointed this out.

--Johan

From frode@dxcern.cern.ch Fri Feb 16 05:32:57 1996
Received: from dxmint.cern.ch (dxmint.cern.ch [137.138.26.76]) by tapr.org (8.7.3/8.7.3/1.8) with SMTP id FAA06579 for <hfsig@tapr.org>; Fri, 16 Feb 1996 05:32:44 -0600 (CST)
Received: from dxcern.cern.ch by dxmint.cern.ch
	id AA15143; Fri, 16 Feb 1996 12:32:08 +0100
Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA29684; Fri, 16 Feb 1996 12:32:07 +0100
Date: Fri, 16 Feb 1996 12:32:06 +0100 (MET)
From: Frode Weierud <frode@dxcern.cern.ch>
To: hfsig@tapr.org
Subject: Re: [HFSIG:891] Re: Sync Vectors for HF Digital
In-Reply-To: <Pine.OSF.3.91.960215085929.31390C-100000@ucs.orst.edu>
Message-Id: <Pine.ULT.3.91.960216121418.29122A-100000@dxcern.cern.ch>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 15 Feb 1996, Johan Forrer wrote:

> Last night I did a bit of reading up and see the Barker sequence has very 
> good properties. The main issue is the autocorrelation function that give 
> a high only at the perfect sync position and next to nil when offset by 
> any other amount. The book also stated that the right PN sequence may be  
> as good as a Barker sequence in many situations. The maximum length 
> known Barker sequence is only 13 bits long.
> 
> Thanks to Kok Chen that also pointed this out.
> 

I have promised to give Johan some references on synchronisation that I 
have recently been looking at. As I suppose others might be interested as 
well, I will post them here.

There are specially three references dealing with Code-assisted bit 
synchronisation (CABS) that combine synchronisation and error-correction 
coding.

P. Couton, C. Hannaford and B. Honary, "Coding for both protection and 
synchronisation", IEE Proc. Commun. Vol. 142, No.6, Dec. 1995, pp.352-356.

This is a more general paper on the use of CABS with other waveforms than 
MFSK, which is the subject of the next two papers.

B. Honary, F. Zolghadr and M. Darnell, "Code-assisted bit synchronisation 
(CABS) scheme", Electronic Letters, vol.25, No.2, pp.152-153.

B. Honary, F. Zolghadr, M. Darnell and M. Maundrell, "Improved HF modem 
using convolutional coding", Electronics & Communication Engineering 
Journal, Vol.4, No.2, April 1992, pp.73-82.

Concerning Barker sequences and word synchronisation generally the next 
paper has a very good analysis.

M. Grayson and M. Darnell, "Extended analysis of word synchronisation 
using sequence correlation techniques", IEE Proc. Commun. Vol. 142, No.6, 
Dec. 1995, pp.357-362.

Johan was earlier asking for references on punctured codes. I know I have 
some other references somewhere, but here is at least one that I have 
briefly had a look at last year.

Jack Keil Wolf and Ephraim Zehavi, "P^2 Codes: Pragmatic Trellis Codes 
Utilizing Punctured Convolutional Codes", IEEE Communication Magazine, 
Feb. 1995, pp.94-99.

Have an enjoyable read, :-)

73's Frode

	Frode Weierud			Phone	: 41 22 7674794
	CERN, SL			Fax	: 41 22 7679185
	CH-1211 Geneva 23, Switzerland	E-mail	: frode@dxcern.cern.ch

From forrerj@ucs.orst.edu  Fri Feb 16 11:49:36 1996
Received: from ucs.orst.edu (root@UCS.ORST.EDU [128.193.4.5]) by tapr.org (8.7.3/8.7.3/1.8) with SMTP id LAA19899 for <hfsig@tapr.org>; Fri, 16 Feb 1996 11:49:32 -0600 (CST)
Received: from p07.t0.monrotel.com by ucs.orst.edu; (5.65v3.2/1.1.8.2/24Sep94-1201PM)
	id AA11073; Fri, 16 Feb 1996 09:48:59 -0800
Message-Id: <9602161748.AA11073@ucs.orst.edu>
X-Sender: forrerj@ucs.orst.edu
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 16 Feb 1996 09:53:56 -0800
To: hfsig@tapr.org
From: forrerj@ucs.orst.edu (Johan Forrer)
Subject: Re: [HFSIG:892] Re: Sync Vectors for HF Digital

Dear Frode,

Thank you for the references. I have seen some of those and they are quite
interesting.

>I have promised to give Johan some references on synchronisation that I 
>have recently been looking at. As I suppose others might be interested as 
>well, I will post them here.
>
>There are specially three references dealing with Code-assisted bit 
>synchronisation (CABS) that combine synchronisation and error-correction 
>coding.
>

As you might have guessed - I am in the process of putting together some
rudimentary definition for use as a data link layer. I like Phil's general
proposal in this regard with a few provisions to make it work on HF. I then
propose to define it as:

1) Hybrid type II ARQ. - frame/cycle time timing fixed. 
   More on the Hybrid ARQ later.
2) Convolutional code with constraint length 7.
3) Fixed symbol rate - data rate variable by use of punctured 
   code in addition to data compression.

It appears that there are some choices for the frame sync sequence. The
13-bit Barker sequence looks like a good choice - unless someone has a good
argument against it. Detecting the sequence or deriving bit timing, is where
CABS may be used with additional advantage as it is Viterbi decoder.
Experience has taught us, however, that bit sync for HF data must be a
dynamic process that is applied throughout the bit stream and one cannot
rely only on timing achieved at the sync vector. The sole purpose of the
sync vector is to find the beginning of the frame. This is particularly
valid when dealing with frames of any significant time duration.

The next question is then:

What should one use for the reverse channel signaling, i.e., the ACK's and
NAK's etc. 
I understand that longish (12 bits for example) PN sequences works
reasonably well.
 
For those that are not familiar with what these are used for - when the
sending station sends a data frame, the receiver need to signal back that it
decoded the previous frame correctly and awaits the next frame. Or if it
decoded an error, in the type II scheme, the sender will send some more
coding bits, not the whole frame - this will help the receiver to "patch up
the frame" using error-correction techniques (the incentive being that much
shortened frames are sent, and thus increased throughput results). A problem
exsists, however, when the sending station fails to read the ACK/NACK
(perhaps due to interference or fading, or it is garbled.) One can see that
a "weak" system of ACK/NACK's , also called the "reverse channel", will tend
to give low throughput or even disastrous link failure when conditions are
marginal. Designing strong reverse channel signalling is as important as the
forward channel coding. 

OK, with that out of the way - with the similar arguments as for the sync
vector selection, PN sequences have been proven to be very powerful for use
in reverse channel signaling. Keep in mind that the actual ACK/NACK
*CHANGES* with every frame (of course the sender and receiver uses the same
PN generator algorithm so they know what to expect). The question is whether
there is something better and how long a sequence do we need?? 


Any suggestions/critisism/ideas on the proposed scheme are welcome.

Thanks,

--Johan, KC7WW


From chbrain@dircon.co.uk  Sat Feb 17 01:52:49 1996
Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by tapr.org (8.7.3/8.7.3/1.8) with SMTP id BAA02598 for <hfsig@tapr.org>; Sat, 17 Feb 1996 01:52:47 -0600 (CST)
Received: from nameserver.dircon.co.uk (gw2-107.pool.dircon.co.uk) by felix.dircon.co.uk with SMTP id AA23485
  (5.67b/IDA-1.5 for <hfsig@tapr.org>); Sat, 17 Feb 1996 07:52:38 GMT
Message-Id: <199602170752.AA23485@felix.dircon.co.uk>
X-Sender: chbrain@popmail.dircon.co.uk
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 17 Feb 1996 07:22:50 +0000
To: hfsig@tapr.org
From: chbrain@dircon.co.uk (Charles Brain)
Subject: Re: [HFSIG:893] Re: Sync Vectors for HF Digital

Hello Johan,
>a "weak" system of ACK/NACK's , also called the "reverse channel", will 
>--Johan, KC7WW

Another idea to throw into the melting pot, if you send a data block and 
hear no ACK/NAK i.e you timeout, should you send the data block again
or simply request the last ACK/NAK to be resent ? I tried this on a simple
H.F protocol a while back, this protocol had a window of one and it did seem
to improve things especially as the transmitted data blocks were very long,
(I was using very deep interleaving) and took a long time to resend.

I guess if the data blocks are short there is no need to do this.

Regards Charles G4GUO

From FORRERJ@frl.orst.edu Mon Feb 19 13:20:13 1996
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by tapr.org (8.7.3/8.7.3/1.8) with SMTP id NAA20906 for <HFSIG@TAPR.ORG>; Mon, 19 Feb 1996 13:20:10 -0600 (CST)
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.118.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with ESMTP id LAA11406 for <HFSIG@TAPR.ORG>; Mon, 19 Feb 1996 11:16:27 -0800
Received: from FRL/SpoolDir by frl.orst.edu (Mercury 1.21);
    19 Feb 96 11:27:09 PST8PDT
Received: from SpoolDir by FRL (Mercury 1.21); 19 Feb 96 11:26:51 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: HFSIG@tapr.org
Date:          Mon, 19 Feb 1996 11:26:51 -0800
Subject:       More BPSK news
Priority: normal
X-mailer: Pegasus Mail v3.22
Message-ID: <2F9BD135F09@frl.orst.edu>

Hi all,

Some more news on BPSK experiments on HF.

Contact was made on 10.137 between Paul, PA0OCD and Timo, OH2LVZ on Sunday 
February 19th using the SP9VRC program. Congratulations! 

Copy was about 80% with signals being weak and in the noise. I believe 
that signals was inaudible most of the time. Paul was using the 56002EVM 
and Timo the DSP4.

It is evident that the trick is how to find the correct frequency. The 
software will track slight off-frequency operation, however, good frequency 
resolution is needed on the tranceivers. Paul suggested that a good 
realtime FFT analyser program is good for this purpose. When used in 
persistance/integrate mode, these weak signals can clearly be seen.

Keep in mind that no error-correcting coding is used at the present time, 
its a good demodulator and the relatively long symbol times that does it. I 
think Pawel is ready to play with some ECC next?

I also have been hearing from Cliff, W6HDO, that he hears my beacon in the 
early mornings. If there is anyone here in the US interested in BPSK 
or high speed OFDM, please let me know so we can arrange for a sked time 
and frequency.

Congratulations again and keep up the good work.

--Johan, KC7WW


From FORRERJ@frl.orst.edu Wed Feb 21 11:59:41 1996
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by tapr.org (8.7.3/8.7.3/1.8) with SMTP id LAA04487 for <HFSIG@TAPR.ORG>; Wed, 21 Feb 1996 11:59:34 -0600 (CST)
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.118.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with ESMTP id JAA19252 for <HFSIG@TAPR.ORG>; Wed, 21 Feb 1996 09:55:45 -0800
Received: from FRL/SpoolDir by frl.orst.edu (Mercury 1.21);
    21 Feb 96 10:06:29 PST8PDT
Received: from SpoolDir by FRL (Mercury 1.21); 21 Feb 96 10:06:28 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: HFSIG@tapr.org
Date:          Wed, 21 Feb 1996 10:06:25 -0800
Subject:       QST tidbits
Priority: normal
X-mailer: Pegasus Mail v3.22
Message-ID: <328676C1A2D@frl.orst.edu>

Hi all,

Wonder if you had a chance to look at the latest issue of QST yet?

It contains an interesting article by Grant Zehr on using JVFAX 7.1. 
The article includes the description of an analog APT convertor as well. 
You might be interested to know that this same functionality and a lot more 
is offered by using Pawel's FSKIFACE program for the 56K EVM. For example, 
you also get full transmit capability for WEFAX and SSTV, if that may be 
of interest to you. The FSKIFACE program for the EVM is included in the 
latest EVM software package on the HFSIG upload area.

The other tidbit that came as a surprize. Looking closely at the 
advertisement of AEA's latest DSP box, I noticed that the DSP used in 
that product is an Analog Devices 2105 DSP. The baoard also contains a 
Motorola 68K family microcontroller. This arrangement appears to offer 
potential for all sorts of future applications.

HAL also shows their new stand-alone Clover unit. Instead of the usual PC-
plugin card, the unit is self-contained. I am not sure whether this 
one uses the older 56001 design or the 320C25 design as used in the P38. 
Someone may wish to comment on that.

MFJ have been offereing a DSP option for some of their HF all-
mode units, though it appears to me as if it is some kind of pre-filter DSP 
arrangement instead of a DSP modem.

It certainly look like DSP is making it into a lot of amateur radio gear 
these days. 
  
73's

--Johan, KC7WW







--Johan

From frode@dxcern.cern.ch Thu Feb 22 04:10:05 1996
Received: from dxmint.cern.ch (dxmint.cern.ch [137.138.26.76]) by tapr.org (8.7.3/8.7.3/1.8) with SMTP id EAA20909 for <hfsig@tapr.org>; Thu, 22 Feb 1996 04:10:03 -0600 (CST)
Received: from dxcern.cern.ch by dxmint.cern.ch
	id AA00726; Thu, 22 Feb 1996 11:09:30 +0100
Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA03034; Thu, 22 Feb 1996 11:09:30 +0100
Date: Thu, 22 Feb 1996 11:09:29 +0100 (MET)
From: Frode Weierud <frode@dxcern.cern.ch>
To: hfsig@tapr.org
Subject: Re: [HFSIG:896] QST tidbits
In-Reply-To: <328676C1A2D@frl.orst.edu>
Message-Id: <Pine.ULT.3.91.960222095839.29501A-100000@dxcern.cern.ch>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 21 Feb 1996, Johan Forrer wrote:

> The other tidbit that came as a surprize. Looking closely at the 
> advertisement of AEA's latest DSP box, I noticed that the DSP used in 
> that product is an Analog Devices 2105 DSP. The baoard also contains a 
> Motorola 68K family microcontroller. This arrangement appears to offer 
> potential for all sorts of future applications.

To see the technical details of the DSP232 have a look at AEA's home page 
URL: http://www.mvangel.com/aea/

Frode

	Frode Weierud			Phone	: 41 22 7674794
	CERN, SL			Fax	: 41 22 7679185
	CH-1211 Geneva 23, Switzerland	E-mail	: frode@dxcern.cern.ch

From 72253.2602@compuserve.com Thu Feb 22 05:36:55 1996
Received: from arl-img-6.compuserve.com (arl-img-6.compuserve.com [198.4.7.6]) by tapr.org (8.7.3/8.7.3/1.8) with SMTP id FAA23442 for <hfsig@tapr.org>; Thu, 22 Feb 1996 05:36:54 -0600 (CST)
Received: by arl-img-6.compuserve.com (8.6.10/5.950515)
	id GAA01799; Thu, 22 Feb 1996 06:36:38 -0500

Date: 22 Feb 96 06:35:30 EST
From: Peter Schulze <72253.2602@compuserve.com>
To: HFSIG <hfsig@tapr.org>
Subject: Re: DSP4100
Message-ID: <960222113530_72253.2602_EHJ48-5@CompuServe.COM>

The DSP4100 is using a design similar to the 4000 boards with the 56000 as DSP.
The 68000 now is a 12Mhz version. Large FlashRoms keep all the code. 
Ram size has been extended too and the long sockets are there for even larger Ram chips.
They need the power to run their new 2khz clover on the units.

Please see my complete review of the unit in the February issue of the
digital journal (http://www.iea.com/~adrs) for more details.

73
Peter TY1PS


-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
EURAF / DTS
B.P. 06-2535, Cotonou, BENIN
Tel.: +229-313779
Fax : +229-313879
72253.2602@compuserve.com
Latest DTS info on the WEB:
http://ourworld.compuserve.com/homepages/EURAF
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

From forrerj@ucs.orst.edu  Thu Feb 22 12:05:43 1996
Received: from ucs.orst.edu (root@UCS.ORST.EDU [128.193.4.5]) by tapr.org (8.7.3/8.7.3/1.8) with SMTP id MAA08816 for <hfsig@tapr.org>; Thu, 22 Feb 1996 12:05:41 -0600 (CST)
Received: from p06.t0.monrotel.com by ucs.orst.edu; (5.65v3.2/1.1.8.2/24Sep94-1201PM)
	id AA27968; Thu, 22 Feb 1996 10:05:21 -0800
Message-Id: <9602221805.AA27968@ucs.orst.edu>
X-Sender: forrerj@ucs.orst.edu
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 22 Feb 1996 10:11:04 -0800
To: hfsig@tapr.org
From: forrerj@ucs.orst.edu (Johan Forrer)
Subject: Re: [HFSIG:894] Re: Sync Vectors for HF Digital

Charles,


>Hello Johan,
>>a "weak" system of ACK/NACK's , also called the "reverse channel", will 
>>--Johan, KC7WW
>
>Another idea to throw into the melting pot, if you send a data block and 
>hear no ACK/NAK i.e you timeout, should you send the data block again
>or simply request the last ACK/NAK to be resent ? 

This is a problem area when sending partial coded blocks. Here is how I see
it: If the receiver read a block perfectly, and it's ACK reponse gets lost
(times out as you say), we simply resend the last block.  Although the
receiving end expects the next block, it will see that the packet counter
has not been incremented nor did the sync vector change and thus knows that
it is a repeat. Only if the sender gets requested specifically to act upon a
block received in error will it send another layer of coding bits.  

Does this make sense?

>I tried this on a simple
>H.F protocol a while back, this protocol had a window of one and it did seem
>to improve things especially as the transmitted data blocks were very long,
>(I was using very deep interleaving) and took a long time to resend.
>
>I guess if the data blocks are short there is no need to do this.
>
>Regards Charles G4GUO
>
>

I do think this idea of shortened blocks, invertible codes, and punctured
code for variable coding rate, should pay off in overall transmitting times.
One thing though that one must guard against is a protocol that has too many
default timeout counters - this is where things break down, i.e., when one
gets in the middle of a speed change and for example, interference sets in
during some crucial link status update stage. All it takes is one missed
state and the PN sequences are out of step.

Sounds like a lot of fun.

--Johan


From forrerj@ucs.orst.edu  Thu Feb 22 12:30:13 1996
Received: from ucs.orst.edu (root@UCS.ORST.EDU [128.193.4.5]) by tapr.org (8.7.3/8.7.3/1.8) with SMTP id MAA09519 for <hfsig@tapr.org>; Thu, 22 Feb 1996 12:30:11 -0600 (CST)
Received: from p09.t0.monrotel.com by ucs.orst.edu; (5.65v3.2/1.1.8.2/24Sep94-1201PM)
	id AA22325; Thu, 22 Feb 1996 10:30:04 -0800
Message-Id: <9602221830.AA22325@ucs.orst.edu>
X-Sender: forrerj@ucs.orst.edu (Unverified)
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 22 Feb 1996 10:35:39 -0800
To: hfsig@tapr.org
From: forrerj@ucs.orst.edu (Johan Forrer)
Subject: Re: [HFSIG:898] Re: DSP4100

Hello Peter,

Thanks for the pointer to your review article - I found it very informative.
Good job!

>The DSP4100 is using a design similar to the 4000 boards with the 56000 as DSP.
>The 68000 now is a 12Mhz version. Large FlashRoms keep all the code. 
>Ram size has been extended too and the long sockets are there for even
larger Ram chips.
>They need the power to run their new 2khz clover on the units.

I don't think this is a typo about the 2kHz Clover units - could you please
expand a bit on what this is about. I thought HAL was pushing for 500 Hz
bandwidth, but perhaps this is a new development? Four parallel Clover
channels = 2 kHz bandwidth, at roughly 800 x 4 = 3200 bps. In my opinion,
this is a welcome and needed step in the right direction. 

Judging from your description, I can see why a better 68K controller was
needed. This is one aspect that is often overlooked - the DSP front-end
hardware effort is minimal compared to what is involved in the protocol
controller.

Thanks for the contribution, Peter.


>
>Please see my complete review of the unit in the February issue of the
>digital journal (http://www.iea.com/~adrs) for more details.
>
>73
>Peter TY1PS
>
>
>-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
>EURAF / DTS
>B.P. 06-2535, Cotonou, BENIN
>Tel.: +229-313779
>Fax : +229-313879
>72253.2602@compuserve.com
>Latest DTS info on the WEB:
>http://ourworld.compuserve.com/homepages/EURAF
>-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
>
>


--Johan, KC7WW

From chbrain@dircon.co.uk  Thu Feb 22 15:33:11 1996
Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by tapr.org (8.7.4/8.7.3/1.8) with SMTP id PAA17669 for <hfsig@tapr.org>; Thu, 22 Feb 1996 15:33:07 -0600 (CST)
Received: from nameserver.dircon.co.uk (gw2-152.pool.dircon.co.uk) by felix.dircon.co.uk with SMTP id AA29500
  (5.67b/IDA-1.5 for <hfsig@tapr.org>); Thu, 22 Feb 1996 21:33:07 GMT
Message-Id: <199602222133.AA29500@felix.dircon.co.uk>
X-Sender: chbrain@popmail.dircon.co.uk
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 22 Feb 1996 21:02:07 +0000
To: hfsig@tapr.org
From: chbrain@dircon.co.uk (Charles Brain)
Subject: Re: [HFSIG:899] Re: Sync Vectors for HF Digital

>it is a repeat. Only if the sender gets requested specifically to act upon a
>block received in error will it send another layer of coding bits.  
>
>Does this make sense?
>
>
Yep it makes sense,
 
 I think some (all!) of Phil's ideas are worth while. I think he has a
postscript
 file on his www page describing them.

A lot of the complexity I have seen in STANAG and MIL-STD protocols
is to do with allowing pre-emption of traffic when higher priority stuff
comes in, something we don't have to worry about?!

I was reading a SHAPE report that came to the conclusion that adapting
the modulation scheme was far more important than changing the data link
parameters. Well that was the understanding I got from it!

Regards Charles G4GUO. 

From frode@dxcern.cern.ch Fri Feb 23 09:34:50 1996
Received: from dxmint.cern.ch (dxmint.cern.ch [137.138.26.76]) by tapr.org (8.7.4/8.7.3/1.8) with SMTP id JAA02371 for <hfsig@tapr.org>; Fri, 23 Feb 1996 09:34:47 -0600 (CST)
Received: from dxcern.cern.ch by dxmint.cern.ch
	id AA11455; Fri, 23 Feb 1996 11:24:22 +0100
Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA26366; Fri, 23 Feb 1996 11:24:21 +0100
Date: Fri, 23 Feb 1996 11:24:21 +0100 (MET)
From: Frode Weierud <frode@dxcern.cern.ch>
To: hfsig@tapr.org
Subject: Re: [HFSIG:900] Re: DSP4100
In-Reply-To: <9602221830.AA22325@ucs.orst.edu>
Message-Id: <Pine.ULT.3.91.960223112226.25523A-100000@dxcern.cern.ch>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 22 Feb 1996, Johan Forrer wrote:

> I don't think this is a typo about the 2kHz Clover units - could you please
> expand a bit on what this is about. I thought HAL was pushing for 500 Hz
> bandwidth, but perhaps this is a new development? Four parallel Clover
> channels = 2 kHz bandwidth, at roughly 800 x 4 = 3200 bps. In my opinion,
> this is a welcome and needed step in the right direction. 
> 

Here is some info distributed on the WUN Mailing list:

>From BrunoUSA@aol.comFri Feb 23 11:21:58 1996
Date: Wed, 24 Jan 1996 00:05:05 -0500
From: BrunoUSA@aol.com
To: wun@grove.net
Subject: [WUN] CLOVER-2000 (Q-CLOVER, Quad-CLOVER) listen-in !

If any of you are interested in "listening" to this new digital
communications mode, tune your receivers to 11.0776 MHz  or  10.3976 MHz, USB
starting at 09h00 PST, Wednesday, January 24th.

We will be experimenting the "beta" CLOVER-2000 (Q-CLOVER or Quad-CLOVER as
it is also called) between our base in Escondido, California and a remote
site in Illinois.
CLOVER-2000 is similar to standard CLOVER except that it is 2KHz wide and is
comprized of 8-tones (both phase & amplitude modulated)... it sounds quite
different friom "regular" CLOVER.
We are running 100 Watts PEP into a 16 element LPDA @ 65' in California. Our
counterpart also has a LPDA... both are aimed at each other.

This will give you an opportunity of "listening" to this new "sound"...  by
the way, if you monitor these frequencies, you will also hear other more
exotic modes (39-tone, ALE, serial-tone, cypher, etc.) as they are part of
our assigned HF test frequencies.

If you hear us... drop me e-mail at:   bhaineau@cts.com   and I will confirm
valid reports (describe the "sounds" you are hearing... and if you do manage
to decode the traffic, you will earn extra brownie points ;-)

Good listening... 

Bruno Haineault


=====
This is the WUN mailing list.
To post to the list, send a e-mail to :   wun@grove.net
To unsubscribe the list, send a mail to:  majordomo@grove.net
with only "unsubscribe wun" in the BODY of the e-mail.
=====


---------------------

73's Frode


	Frode Weierud			Phone	: 41 22 7674794
	CERN, SL			Fax	: 41 22 7679185
	CH-1211 Geneva 23, Switzerland	E-mail	: frode@dxcern.cern.ch

From k5yfw@sacdm01.kelly.af.mil  Fri Feb 23 13:15:41 1996
Received: from sacdm01.kelly.af.mil ([137.242.64.1]) by tapr.org (8.7.4/8.7.3/1.8) with SMTP id NAA10477 for <hfsig@tapr.org>; Fri, 23 Feb 1996 13:11:39 -0600 (CST)
Received:  by sacdm01.kelly.af.mil (5.65b/1.0.2-rct)
	id AA16763; Fri, 23 Feb 96 12:54:35 -0600
Message-Id: <9602231854.AA16763@sacdm01.kelly.af.mil>
Date: Fri, 23 Feb 96 12:54:31 -0600
From: k5yfw@sacdm01.kelly.af.mil (WALT DUBOSE - K5YFW)
Subject: CLOVER 2000 (Q-CLOVER)
To: bhaineau@cts.com
Cc: hfsig@tapr.org
X-Orig-Date: Fri, 23 Feb 1996 09:47:24 -0600 (CST)
X-Orig-From: Frode Weierud <frode@dxcern.cern.ch>
X-Orig-Message-Id: <Pine.ULT.3.91.960223112226.25523A-100000@dxcern.cern.ch>

Bruno,

_BRAVO_

I believe you are on the _right_ track now.  A couple of years ago I
corresponded with the originators of CLOVER and expressed my belief
that hams need to quickly move to multi-tone modems of 16 to 39 tones
similar to the MIL-STD-188-110c type modems.  Shortly after that I
began corresponding with several members on the TAPR HFSIG.

I am particularly impressed to see that HAL is moving up to higher
bit rates and now has an external clover board...this is very
important in emergency communications.

I am presenting a program on HF digital communications to the San
Antonio Radio Club next month and will use as a major part of my
presentation the information (papers) supplied by HAL on the CLOVER
system had were re-prints of magazine articles.  I would be most
interested in obtaining the same type of information about Q-CLOVER.

While I was Chief of Communications Maintenance for the 32nd
Aeromedical Evacuation Gp (and senior communicator in the AF
Aeromedical Evacuation System) I pushed for use of the
MIL-STD-188-110c modems (16/39 tone and serial tone) use, but the
price limited our obtaining the modems (about $10K at the time).  Our
requirement was 2400 BPS data thruput under adverse HF conditions at
the 100 Watt power level.  As deputy communications director for the
San Antonio Emergency Management Communications Gp (pronounce that
Civil Defense Communications) I see the above requirement for our use,
especially in providing command and control communications from the
Texas Gulf Coast back to San Antonio during hurricanes.

Additionally, we have a requirement to run TCP/IP on HF...3200 BPS
(assuming 1000 BPS for FEC) would meet that need.  Please consider
writing encapsulation software for the CLOVER-200 (Q-CLOVER) modem
allowing it to run TCP/IP over HF.

I am looking forward to hearing from you.  The top part of my tower
is still on the ground so my LP is still on the ground and I won't be
able to hear your test.

Best Regards,

Walt DuBose

==================================================================

In Frode's message of 23 Feb 1996 at 0947 CST, he writes:
> On Thu, 22 Feb 1996, Johan Forrer wrote:
>
> > I don't think this is a typo about the 2kHz Clover units - could you please
> > expand a bit on what this is about. I thought HAL was pushing for 500 Hz
> > bandwidth, but perhaps this is a new development? Four parallel Clover
> > channels = 2 kHz bandwidth, at roughly 800 x 4 = 3200 bps. In my opinion,
> > this is a welcome and needed step in the right direction.
> >
>
> Here is some info distributed on the WUN Mailing list:
>
> >From BrunoUSA@aol.comFri Feb 23 11:21:58 1996
> Date: Wed, 24 Jan 1996 00:05:05 -0500
> >From: BrunoUSA@aol.com
> To: wun@grove.net
> Subject: [WUN] CLOVER-2000 (Q-CLOVER, Quad-CLOVER) listen-in !
>
> If any of you are interested in "listening" to this new digital
> communications mode, tune your receivers to 11.0776 MHz  or  10.3976 MHz, USB
> starting at 09h00 PST, Wednesday, January 24th.
>
> We will be experimenting the "beta" CLOVER-2000 (Q-CLOVER or Quad-CLOVER as
> it is also called) between our base in Escondido, California and a remote
> site in Illinois.
> CLOVER-2000 is similar to standard CLOVER except that it is 2KHz wide and is
> comprized of 8-tones (both phase & amplitude modulated)... it sounds quite
> different friom "regular" CLOVER.
> We are running 100 Watts PEP into a 16 element LPDA @ 65' in California. Our
> counterpart also has a LPDA... both are aimed at each other.
>
> This will give you an opportunity of "listening" to this new "sound"...  by
> the way, if you monitor these frequencies, you will also hear other more
> exotic modes (39-tone, ALE, serial-tone, cypher, etc.) as they are part of
> our assigned HF test frequencies.
>
> If you hear us... drop me e-mail at:   bhaineau@cts.com   and I will confirm
> valid reports (describe the "sounds" you are hearing... and if you do manage
> to decode the traffic, you will earn extra brownie points ;-)
>
> Good listening...
>
> Bruno Haineault
>
>
> =====
> This is the WUN mailing list.
> To post to the list, send a e-mail to :   wun@grove.net
> To unsubscribe the list, send a mail to:  majordomo@grove.net
> with only "unsubscribe wun" in the BODY of the e-mail.
> =====
>
>
> ---------------------
>
> 73's Frode
>
>
>             Frode Weierud                          Phone            : 41
22 7674794 
>             CERN, SL                    Fax      : 41 22 7679185
>

From karn@qualcomm.com Fri Feb 23 18:46:26 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org (8.7.4/8.7.3/1.8) with ESMTP id SAA22678 for <hfsig@tapr.org>; Fri, 23 Feb 1996 18:46:24 -0600 (CST)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.3/8.7.2/1.6.1) id QAA05605; Fri, 23 Feb 1996 16:45:51 -0800 (PST)
Date: Fri, 23 Feb 1996 16:45:51 -0800 (PST)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199602240045.QAA05605@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <9602161748.AA11073@ucs.orst.edu> (forrerj@ucs.orst.edu)
Subject: Re: [HFSIG:893] Re: Sync Vectors for HF Digital

>It appears that there are some choices for the frame sync sequence. The
>13-bit Barker sequence looks like a good choice - unless someone has a good
>argument against it. Detecting the sequence or deriving bit timing, is where

Well, my main objection to Barker sequences is that the longest known
Barker sequence isn't very long. Since the sync vectors are sent
without ECC, and because the ECC code rate might be very low, you need
extreme robustness in your sync vector. That argues for a fairly long
sync vector, much longer than 13 bits.

You can think of a PN sync sequence as a "spread spectrum burst" conveying
one bit of information ("the packet starts HERE") with a considerable
processing gain equal to the number of bits in the sequence. A 64-bit PN
sequence gives a processing gain of 64:1 or about 18 dB, which should be
enough to keep working reliably even at the extremely low symbol S/Ns
implied by powerful, low rate ECC.

Phil

From hstr@gil.com.au Fri Feb 23 18:49:23 1996
Received: from iccu6.ipswich.gil.com.au (iccu6.ipswich.gil.com.au [203.1.75.10]) by tapr.org (8.7.4/8.7.3/1.8) with ESMTP id SAA23074 for <hfsig@tapr.org>; Fri, 23 Feb 1996 18:49:16 -0600 (CST)
Received: from cs1p11.ipswich.gil.com.au (cs1p11.ipswich.gil.com.au [203.1.75.158]) by iccu6.ipswich.gil.com.au with SMTP id TAA17928
  (8.6.12/IDA-1.6 for <hfsig@tapr.org>); Fri, 23 Feb 1996 19:48:42 -0500
Message-ID: <199602240048.TAA17928@iccu6.ipswich.gil.com.au>
Comments: Authenticated sender is <hstr@mail.ipswich.gil.com.au>
From: "Helmut Strickner" <hstr@gil.com.au>
To: hfsig@tapr.org
Date: Sat, 24 Feb 1996 10:48:59 +1000
Subject: EVM56002 connecting to printer port
Priority: normal
X-mailer: Pegasus Mail for Windows (v2.23)

Hi

I have downloaded the latest evm27.zip file from the Motorola bubfile 
archive (design.NET site) and found an archive in it called spec.zip.

It contains some programmes, one of them is a frequency domain plot 
program which runs on the PC. In this example the FFT is performed on 
the EVM56002 which is connected to the PC parallel port via a cable 
from J7. There is a file in the archive called spec2.doc which contains
the description of the program and shows how to connect the Port B of 
the DSP56002 which is J7 to the parallel port on the PC.

The problem is that I am unable to read this doc file, it is not in 
word format but has a label at the beginning of the file <MakerFile 
4.0K>. Can somebody please tell me how to read or convert this file 
into a readable and printable format? It contains some graphics about 
the cable connection from J7 to the parallel port.

If someone has already converted this file is it possible to upload 
it to hfsig/upload directory please.

I think to ask Motorola to post this file in a 'standard' format will 
take months of waiting. It took them two months to sort out the 
problems with the corrupt evm27.exe file in the bubfile archive.

Helmut
  

From kurpiers@zeus.uet.e-technik.th-darmstadt.de Sat Feb 24 00:26:19 1996
Received: from rs2.hrz.th-darmstadt.de (rs2.hrz.th-darmstadt.de [130.83.22.63]) by tapr.org (8.7.4/8.7.3/1.8) with SMTP id AAA11606 for <hfsig@tapr.org>; Sat, 24 Feb 1996 00:26:16 -0600 (CST)
Received: from zeus (zeus.uet.e-technik.th-darmstadt.de [130.83.18.75]) by rs2.hrz.th-darmstadt.de (8.6.12/8.6.12.1ms) with ESMTP id HAA08746 for <hfsig@tapr.org>; Sat, 24 Feb 1996 07:26:12 +0100
Received: from hades.uet.e-technik.th-darmstad (hades.uet.e-technik.th-darmstadt.de [130.83.18.78]) by zeus (8.7.1/8.6.9-HRZ) with ESMTP id HAA20830 for <hfsig@tapr.org>; Sat, 24 Feb 1996 07:26:11 +0100
Received: (from kurpiers@localhost) by hades.uet.e-technik.th-darmstad (8.7.1/8.7.1-HRZ-Fwd2.2) id HAA21288; Sat, 24 Feb 1996 07:26:10 +0100
Date: Sat, 24 Feb 1996 07:26:10 +0100 (MEZ)
From: Alexander Kurpiers <kurpiers@zeus.uet.e-technik.th-darmstadt.de>
To: hfsig@tapr.org
Subject: Re: [HFSIG:904] Re: Sync Vectors for HF Digital
In-Reply-To: <199602240045.QAA05605@servo.qualcomm.com>
Message-ID: <Pine.A32.3.91.960224072316.19236A-100000@hades.uet.e-technik.th-darmstadt.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 23 Feb 1996, Phil Karn wrote:

> >It appears that there are some choices for the frame sync sequence. The
> >13-bit Barker sequence looks like a good choice - unless someone has a good
> >argument against it. Detecting the sequence or deriving bit timing, is where
> 
> Well, my main objection to Barker sequences is that the longest known
> Barker sequence isn't very long. Since the sync vectors are sent
> without ECC, and because the ECC code rate might be very low, you need
> extreme robustness in your sync vector. That argues for a fairly long
> sync vector, much longer than 13 bits.
> 

The longest known binary Barker sequence is 13 bits. But there are lots
of longer Generalized Barker sequences. The longest I know is 36 bits long.
As we don't have to stick to binary sequences there is a possibility to
use Generalized Barker sequences.

> You can think of a PN sync sequence as a "spread spectrum burst" conveying
> one bit of information ("the packet starts HERE") with a considerable
> processing gain equal to the number of bits in the sequence. A 64-bit PN
> sequence gives a processing gain of 64:1 or about 18 dB, which should be
> enough to keep working reliably even at the extremely low symbol S/Ns
> implied by powerful, low rate ECC.
> 
> Phil
> 

Ok, from a practical point of view PN sequences seem to be better.

73' Alexander> 

*----------------------------------+---------------------------------------*
|      Alexander F. Kurpiers       |                                       |
| Institut f. Uebertragungstechnik | Voice: +49-6151-162369                |
|    u. Elektroakustik             | Fax  : +49-6151-165545                |
| Merckstrasse 25                  | EMail: a.kurpiers@uet.th-darmstadt.de |
| D-64283 Darmstadt (Germany)      | Hamradio: dl8aau@db0zdf.#rpl.deu.eu   |
*----------------------------------+---------------------------------------*



From k4gvo@america.net Sat Feb 24 05:22:43 1996
Received: from america.net (atl1.america.net [199.170.121.2]) by tapr.org (8.7.4/8.7.3/1.8) with SMTP id FAA21207 for <hfsig@tapr.org>; Sat, 24 Feb 1996 05:22:41 -0600 (CST)
Message-Id: <199602241122.FAA21207@tapr.org>
Received: from k4gvo (pm1-5.america.net [199.170.121.105]) by america.net (8.6.10/8.6.9) with SMTP id GAA00674; Sat, 24 Feb 1996 06:28:06 -0500
Sender: <k4gvo@atl1.america.net>
From: "Jim Lynch" <k4gvo@america.net>
To: "Helmut Strickner" <hstr@gil.com.au>, hfsig@tapr.org
Date:          Sat, 24 Feb 1996 06:21:13 +0000
Subject:       Re: [HFSIG:905] EVM56002 connecting to printer port
Reply-to: k4gvo@america.net
Priority: normal
X-mailer: Pegasus Mail/Windows (v1.22)

> Date:          Fri, 23 Feb 1996 19:05:35 -0600 (CST)
> Reply-to:      hfsig@tapr.org
> From:          "Helmut Strickner" <hstr@gil.com.au>
> To:            hfsig@tapr.org
> Subject:       [HFSIG:905] EVM56002 connecting to printer port

> Hi
> 
> I have downloaded the latest evm27.zip file from the Motorola bubfile 
> archive (design.NET site) and found an archive in it called spec.zip.
> 
> It contains some programmes, one of them is a frequency domain plot 
> program which runs on the PC. In this example the FFT is performed on 
> the EVM56002 which is connected to the PC parallel port via a cable 
> from J7. There is a file in the archive called spec2.doc which contains
> the description of the program and shows how to connect the Port B of 
> the DSP56002 which is J7 to the parallel port on the PC.
> 
> The problem is that I am unable to read this doc file, it is not in 
> word format but has a label at the beginning of the file <MakerFile 
> 4.0K>. Can somebody please tell me how to read or convert this file 
> into a readable and printable format? It contains some graphics about 
> the cable connection from J7 to the parallel port.
> 
> If someone has already converted this file is it possible to upload 
> it to hfsig/upload directory please.
> 
> I think to ask Motorola to post this file in a 'standard' format will 
> take months of waiting. It took them two months to sort out the 
> problems with the corrupt evm27.exe file in the bubfile archive.
> 
> Helmut
It sounds like that may be a Frame Maker file.  I use (rarely) frame 
maker at work and might be able to translate the file into another 
format, but I'm not sure about the legality of re-distributing it.  
I've seen a "frame viewer" somewhere recently, but don't remember 
where it was.  It ran on a pc, so maybe this will jog someone's 
memory.  I'll keep my eyes open.

Jim.
Jim Lynch           Fayetteville, GA       K4GVO
'86 GL1200I         k4gvo@america.net      44.36.34.20

From gc@fox.cen.com  Sat Feb 24 11:11:42 1996
Received: from uu5.psi.com (uu5.psi.com [38.145.226.3]) by tapr.org (8.7.4/8.7.3/1.8) with SMTP id LAA02584 for <hfsig@tapr.org>; Sat, 24 Feb 1996 11:11:39 -0600 (CST)
Received: from fox.cen.com by uu5.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP;
        id AA27498 for hfsig@tapr.org; Sat, 24 Feb 96 12:11:32 -0500
Received: by cen.com (4.1/SMI-4.1)
	id AA04594; Sat, 24 Feb 96 12:11:31 EST
Date: Sat, 24 Feb 96 12:11:31 EST
From: gc@fox.cen.com (Gary Chatters)
Message-Id: <9602241711.AA04594@cen.com>
To: hfsig@tapr.org
Subject: FrameReader (Was: EVM56002 ...)

>It sounds like that may be a Frame Maker file.  I use (rarely) frame 
>maker at work and might be able to translate the file into another 
>format, but I'm not sure about the legality of re-distributing it.  
>I've seen a "frame viewer" somewhere recently, but don't remember 
>where it was.  It ran on a pc, so maybe this will jog someone's 
>memory.  I'll keep my eyes open.

FrameReader  is available via anonymous ftp at ftp.frame.com.
cd to /pub/techsup/product_updates/dos and get the file: reader.zip.
PKZIP is available on some other branch of the /pub/techsup tree
to unzip the file.  Even in its compressed format this is a 4.7MB file.
mac and unix versions available.

Frame also has a FrameViewer which costs about $20-$30.

On a more general note:  Microsoft Word, Frame, Mathematica, and Adobe
(and others) all have free or cheap viewers available.

Gary

From srbible@mindport.net Sat Feb 24 17:07:12 1996
Received: from polaris.mindport.net (root@polaris.mindport.net [205.219.167.2]) by tapr.org (8.7.4/8.7.3/1.8) with SMTP id RAA16333 for <hfsig@tapr.org>; Sat, 24 Feb 1996 17:07:06 -0600 (CST)
Received: from default (synapse-71.mindport.net [205.219.167.130]) by polaris.mindport.net (8.6.12/8.6.12) with SMTP id SAA27415 for <hfsig@tapr.org>; Sat, 24 Feb 1996 18:07:05 -0500
Posted-Date: Sat, 24 Feb 1996 18:07:05 -0500
Message-Id: <1.5.4b11.32.19960224230716.0067414c@mindport.net>
X-Sender: srbible@mindport.net
X-Mailer: Windows Eudora Light Version 1.5.4b11 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 24 Feb 1996 18:07:16 -0500
To: hfsig@tapr.org
From: "Steven R. Bible" <srbible@mindport.net>
Subject: Re: [HFSIG:908] FrameReader (Was: EVM56002 ...)

Does anyone know of a postscript viewer/reader for Win95?  And to make it
even more challenging, can print to whatever Win95 printer driver is
installed at the time.  Either I have to purchase a postscript printer or
convert postscript files to adobe PDF format.

Thanks, Steve N7HPR



>FrameReader  is available via anonymous ftp at ftp.frame.com.
>cd to /pub/techsup/product_updates/dos and get the file: reader.zip.
>PKZIP is available on some other branch of the /pub/techsup tree
>to unzip the file.  Even in its compressed format this is a 4.7MB file.
>mac and unix versions available.
>
>Frame also has a FrameViewer which costs about $20-$30.
>
>On a more general note:  Microsoft Word, Frame, Mathematica, and Adobe
>(and others) all have free or cheap viewers available.
>
>Gary
>
>
>

From hstr@gil.com.au Sun Feb 25 17:21:56 1996
Received: from iccu6.ipswich.gil.com.au (iccu6.ipswich.gil.com.au [203.1.75.10]) by tapr.org (8.7.4/8.7.3/1.8) with ESMTP id RAA18356 for <hfsig@tapr.org>; Sun, 25 Feb 1996 17:21:52 -0600 (CST)
Received: from cs9p9.ipswich.gil.com.au (cs9p9.ipswich.gil.com.au [203.1.72.72]) by iccu6.ipswich.gil.com.au with SMTP id SAA11458
  (8.6.12/IDA-1.6 for <hfsig@tapr.org>); Sun, 25 Feb 1996 18:21:21 -0500
Message-ID: <199602252321.SAA11458@iccu6.ipswich.gil.com.au>
Comments: Authenticated sender is <hstr@mail.ipswich.gil.com.au>
From: "Helmut Strickner" <hstr@gil.com.au>
To: hfsig@tapr.org
Date: Mon, 26 Feb 1996 09:21:43 +1000
Subject: Re: Re: FrameReader (Was: EVM56002 ...)
Priority: normal
X-mailer: Pegasus Mail for Windows (v2.23)



> Does anyone know of a postscript viewer/reader for Win95?  And to make it
> even more challenging, can print to whatever Win95 printer driver is
> installed at the time.  Either I have to purchase a postscript printer or
> convert postscript files to adobe PDF format.
> 
> Thanks, Steve N7HPR
> 
Have you tried Ghostview and Ghostscript ? They are available under 
the GNU agreement on a number of sites. I am not sure whether there 
is a version out yet which runs under Win95.

As for the Frame Reader programme I have spent about 4 hours 
downloading it before the ftp stalled around the 4Mb mark.
The Frame Reader is freely available and the size of the file is abt. 
4.6MB. Perhaps I will have another try on a luckier day.

Helmut

> 
> 
> >FrameReader  is available via anonymous ftp at ftp.frame.com.
> >cd to /pub/techsup/product_updates/dos and get the file: reader.zip.
> >PKZIP is available on some other branch of the /pub/techsup tree
> >to unzip the file.  Even in its compressed format this is a 4.7MB file.
> >mac and unix versions available.
> >
> >Frame also has a FrameViewer which costs about $20-$30.
> >
> >On a more general note:  Microsoft Word, Frame, Mathematica, and Adobe
> >(and others) all have free or cheap viewers available.
> >
> >Gary
> >
> >
> >
> 
> 
> 

From jbloom@usa.nai.net Mon Feb 26 05:00:41 1996
Received: from usa.nai.net (usa.nai.net [204.71.21.10]) by tapr.org (8.7.4/8.7.3/1.8) with SMTP id FAA19402 for <hfsig@tapr.org>; Mon, 26 Feb 1996 05:00:38 -0600 (CST)
Received: from jbloom.nai.net (jbloom.nai.net [204.71.21.17]) by usa.nai.net (8.6.5/8.6.5) with SMTP id FAA09386 for <hfsig@tapr.org>; Mon, 26 Feb 1996 05:51:45 -0500
Received: by jbloom.nai.net with Microsoft Mail
	id <01BB040F.32048C40@jbloom.nai.net>; Mon, 26 Feb 1996 05:56:39 -0500
Message-ID: <01BB040F.32048C40@jbloom.nai.net>
From: Jon Bloom <jbloom@usa.nai.net>
To: "'hfsig@tapr.org'" <hfsig@tapr.org>
Subject: RE: [HFSIG:910] Re: Re: FrameReader (Was: EVM56002 ...)
Date: Mon, 26 Feb 1996 05:54:01 -0500
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BB040F.3236E6E0"


------ =_NextPart_000_01BB040F.3236E6E0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Helmut Strickner[SMTP:hstr@gil.com.au] wrote:
>
>
>> Does anyone know of a postscript viewer/reader for Win95?  And to =
make it
>> even more challenging, can print to whatever Win95 printer driver is
>> installed at the time.  Either I have to purchase a postscript =
printer or
>> convert postscript files to adobe PDF format.
>>=20
>> Thanks, Steve N7HPR
>>=20
>Have you tried Ghostview and Ghostscript ? They are available under=20
>the GNU agreement on a number of sites. I am not sure whether there=20
>is a version out yet which runs under Win95.

Yes, the 32-bit Ghostscript 3.53 runs under Win95. I use it often, along =
with GSView 1.4, to attach preview bitmaps to EPS files and to view =
Postscript files. (I don't use it to print since I have a Postscript =
printer, but it will print to a Windows printer.)

See http://www.cs.wisc.edu/~ghost/

--Jon

------ =_NextPart_000_01BB040F.3236E6E0
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

eJ8+IicKAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAENgAQAAgAAAAIAAgABBJAG
AAABAAABAAAADAAAAAMAADADAAAACwAPDgAAAAACAf8PAQAAADsAAAAAAAAAgSsfpL6jEBmdbgDd
AQ9UAgAAAABoZnNpZ0B0YXByLm9yZwBTTVRQAGhmc2lnQHRhcHIub3JnAAAeAAIwAQAAAAUAAABT
TVRQAAAAAB4AAzABAAAADwAAAGhmc2lnQHRhcHIub3JnAAADABUMAQAAAAMA/g8GAAAAHgABMAEA
AAARAAAAJ2hmc2lnQHRhcHIub3JnJwAAAAACAQswAQAAABQAAABTTVRQOkhGU0lHQFRBUFIuT1JH
AAMAADkAAAAACwBAOgEAAAACAfYPAQAAAAQAAAAAAAADwSkBCIAHABgAAABJUE0uTWljcm9zb2Z0
IE1haWwuTm90ZQAxCAEEgAEAOAAAAFJFOiBbSEZTSUc6OTEwXSBSZTogUmU6IEZyYW1lUmVhZGVy
IChXYXM6IEVWTTU2MDAyIC4uLikA8w4BBYADAA4AAADMBwIAGgAFADYAAQABACwBASCAAwAOAAAA
zAcCABoABQAvACIAAQBGAQEJgAEAIQAAADA4OUUwQTQ4MDA3MENGMTE5MjU1NDQ0NTUzNTQwMDAw
AKwGAQOQBgAQBQAAEgAAAAsAIwAAAAAAAwAmAAAAAAALACkAAAAAAAMANgAAAAAAQAA5AGCQ/rw4
BLsBHgBwAAEAAAA4AAAAUkU6IFtIRlNJRzo5MTBdIFJlOiBSZTogRnJhbWVSZWFkZXIgKFdhczog
RVZNNTYwMDIgLi4uKQACAXEAAQAAABYAAAABuwQ4vLJICp4JcAARz5JVREVTVAAAAAAeAB4MAQAA
AAUAAABTTVRQAAAAAB4AHwwBAAAADwAAAGpibG9vbUBuYWkubmV0AAADAAYQs6qTVwMABxCQAgAA
HgAIEAEAAABlAAAASEVMTVVUU1RSSUNLTkVSU01UUDpIU1RSQEdJTENPTUFVV1JPVEU6RE9FU0FO
WU9ORUtOT1dPRkFQT1NUU0NSSVBUVklFV0VSL1JFQURFUkZPUldJTjk1P0FORFRPTUFLRUlURQAA
AAACAQkQAQAAAHkDAAB1AwAA+AYAAExaRnWhIpmD/wAKAQ8CFQKoBesCgwBQAvIJAgBjaArAc2V0
MjcGAAbDAoMyA8UCAHByQnER4nN0ZW0CgzM3AuQHEwKDNARGEzMxIHcIVQeyAoB9CoAIzwnZO/EY
DzI1NQKACoENsQtg4G5nMTAzFFALChVhBQvyYwBAIEhlbG0SdQVAU3QFEGNrbgEEkFtTTVRQOmhR
E8ByQGcDEC4FoG3ALmF1XSB3A2AT0Ho6CoU+G88N8BNQH4Fj/wVACocb7yA/IU8iXyNvJHywPiBE
bweRAHB5AiCUZSAdsG8H4G9mKRBYIHBvE8AE9XYIkHfVBJAvGBBhBIEgAhAFwEJXC4A5NT8gFLBu
oGQgdG8gAMBrKXA8aXQlXyZvJ38og2V2nwnwLOAFsClwEXFsbAnw+x6gGxAsMXADkRNQC4AFQP0s
wXcRgBPQMPAr5TKEFrH+ZAUQM3IEAC1vLn8vjyiDvwuAE8AxoiygM0AssGgpcOp0B3EuLGBFLUA5
gAXA3EkgEYAw8CyycAhwEXH/EbAqDDQWBbA1LzY/N08og90FoG4zcTxxKkhmAxAHkRMswStwb2Ip
cFBERvMrsgDAdC49Pz5PP18ogy9Dj0SfRa8og1QRgG5rHnMyMB1gMOEHsDdIUP5SRw9IH0kvRr9M
f02PJNZ2SDrCKUB1LLAIgSygR/5oKkEq4ikRU2UE9SxQSoD8ZXkpEDFROsALcAtgAmD9KXB1LJAW
sU8/UE9RXyUh8TlyR05VKRAJwgeAMsHzAiAqAW51BtA84inwAJDNE9BzOfA6kGFtW5AfgP9cMAhw
KXAzIBHAOlI6Qilw/1bfV+9Y/yUhBAAqATNxAJB3W1EIYAVAeRHAMxEdkGj8IHJWcAQgVnQsA0N4
G587HKNklVkHkDIwOXIzMgwtYi1AVFszLjUze2N/XJJ1O5FnwSngE9BudzIwB0ACIGcfUDoxU3BT
4lZT4jEuNGchQlECQH8A0GNgE1Aw4FPiZ7EAwHD5QiNFUAXwQeRUIizBU9M2UEFNOfAoOpBCgG4n
nwVAakU7AjKjAJBuYylw3zqVKhBvyTQVMjBiHTFnwb8D8DGwMogqECwBQoB3BCB5NBUuKWSVZJUG
YClwaMECQHA6Ly93eLAe0BNcgAPxYy4JgHUvfopnU5IvdywtLUoCIAt3LBcxAHxwAAAAAwAQEAAA
AAADABEQAAAAAEAABzAgCNzVNwS7AUAACDAgCNzVNwS7AR4APQABAAAABQAAAFJFOiAAAAAAuHU=

------ =_NextPart_000_01BB040F.3236E6E0--

From FORRERJ@frl.orst.edu Mon Feb 26 10:43:00 1996
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by tapr.org (8.7.4/8.7.3/1.8) with SMTP id KAA01874 for <hfsig@tapr.org>; Mon, 26 Feb 1996 10:42:58 -0600 (CST)
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.118.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with ESMTP id IAA23942 for <hfsig@tapr.org>; Mon, 26 Feb 1996 08:38:55 -0800
Received: from FRL/SpoolDir by frl.orst.edu (Mercury 1.21);
    26 Feb 96 08:49:51 PST8PDT
Received: from SpoolDir by FRL (Mercury 1.21); 26 Feb 96 08:49:27 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Mon, 26 Feb 1996 08:49:17 -0800
Subject:       Re: [HFSIG:904] Re: Sync Vectors for HF Digital
Priority: normal
X-mailer: Pegasus Mail v3.22
Message-ID: <39F223B3805@frl.orst.edu>

Hi Phil,

For the same argument, I assume that reverse channel signaling for an 
ARQ system needs the same considerations as that is also an unprotected 
sequence?

Any suggestions on what would be suitable there?

> 
> >It appears that there are some choices for the frame sync sequence. The
> >13-bit Barker sequence looks like a good choice - unless someone has a good
> >argument against it. Detecting the sequence or deriving bit timing, is where
> 
> Well, my main objection to Barker sequences is that the longest known
> Barker sequence isn't very long. Since the sync vectors are sent
> without ECC, and because the ECC code rate might be very low, you need
> extreme robustness in your sync vector. That argues for a fairly long
> sync vector, much longer than 13 bits.
> 
> You can think of a PN sync sequence as a "spread spectrum burst" conveying
> one bit of information ("the packet starts HERE") with a considerable
> processing gain equal to the number of bits in the sequence. A 64-bit PN
> sequence gives a processing gain of 64:1 or about 18 dB, which should be
> enough to keep working reliably even at the extremely low symbol S/Ns
> implied by powerful, low rate ECC.
> 
> Phil
> 
>

--Johan 

From N0AOT@aol.com Tue Feb 27 11:38:26 1996
Received: from mail04.mail.aol.com (mail04.mail.aol.com [152.163.172.53]) by tapr.org (8.7.4/8.7.3/1.8) with SMTP id LAA26762 for <hfsig@tapr.org>; Tue, 27 Feb 1996 11:38:24 -0600 (CST)
From: N0AOT@aol.com
Received: by mail04.mail.aol.com (8.6.12/8.6.12) id MAA17623; Tue, 27 Feb 1996 12:37:20 -0500
Date: Tue, 27 Feb 1996 12:37:20 -0500
Message-ID: <960227123719_334589791@mail04.mail.aol.com>
To: forrerj@frl.orst.edu
cc: hfsig@tapr.org, amsat-bb@amsat.org
Subject: Re: [HFSIG:896] QST tidbits

In a message dated 96-02-21 14:08:36 EST, you write:

>Wonder if you had a chance to look at the latest issue of QST yet?
>

Hi Johan--

I haven't talked to you for ages, but have been following your comments here
on the HFSIG. Lots of neat stuff going on!

Here's another tidbit from the bottom of page 183 of Jan 96 QST:  Brian
Beezley, K6STI, is offering an DSP RTTY package which uses the common SB-16
sound card. He describes a graphical FFT tuning indicator and many other
features.  He doesn't say anything about amtor/pactor, though. 

Have you or any of the others tried out this software? I have a sb compatible
chip in my Pentium notebook, and I realized that if it really works, all I
have to do is plug my radio directly into the mike and speaker jack of the
notebook, to be on the air! How's that for simple and portable? 

Now if someone would just write a 9600 baud modem for the pacsats using the
SB-16 and/or Pentium, I could throw out the DSP 2232 (which AEA seems to have
abandoned) along with all the rest of the external modems! 

73's,

--Bob Carlson, n0aot@amsat.org

From cbuttsch@biggulp.callamer.com Tue Feb 27 12:46:56 1996
Received: from biggulp.callamer.com (cbuttsch@biggulp.callamer.com [199.74.141.2]) by tapr.org (8.7.4/8.7.3/1.8) with ESMTP id MAA29528 for <hfsig@tapr.org>; Tue, 27 Feb 1996 12:46:54 -0600 (CST)
Received: (from cbuttsch@localhost) by biggulp.callamer.com (8.7.4/8.7.3) id KAA29920; Tue, 27 Feb 1996 10:46:45 -0800 (PST)
Date: Tue, 27 Feb 1996 10:46:45 -0800 (PST)
From: Clifford Buttschardt <cbuttsch@biggulp.callamer.com>
To: N0AOT@aol.com
cc: hfsig@tapr.org
Subject: Re: [HFSIG:913] Re: QST tidbits
In-Reply-To: <960227123719_334589791@mail04.mail.aol.com>
Message-ID: <Pine.OSF.3.91.960227104126.16938F-100000@biggulp.callamer.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

As you, I am most interested in Brian Beesley's efforts using the sound 
card instead of some of the DSP units that have attempted to do 9600, 
Amtor/Pactor.  These tasks should have already been accomplished by the 
DSP 93 platform by have not!  If this sound card approach does work, I'd 
be most interested in knowing that fact AND knowing just how difficult it 
might be to program for BPSK, DBPSK and similar protocols.
Cliff Buttschardt   W6HDO

From forrerj@ucs.orst.edu Tue Feb 27 17:32:39 1996
Received: from ucs.orst.edu (root@UCS.ORST.EDU [128.193.4.5]) by tapr.org (8.7.4/8.7.3/1.8) with SMTP id RAA12043 for <hfsig@tapr.org>; Tue, 27 Feb 1996 17:32:36 -0600 (CST)
Received: by ucs.orst.edu; (5.65v3.2/1.1.8.2/24Sep94-1201PM)
	id AA12695; Tue, 27 Feb 1996 14:11:44 -0800
Date: Tue, 27 Feb 1996 14:11:42 -0800 (PST)
From: Johan Forrer <forrerj@ucs.orst.edu>
To: hfsig@tapr.org
Subject: Re: [HFSIG:914] Re: QST tidbits
In-Reply-To: <Pine.OSF.3.91.960227104126.16938F-100000@biggulp.callamer.com>
Message-Id: <Pine.OSF.3.91.960227132050.11393C-100000@ucs.orst.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Cliff,

On Tue, 27 Feb 1996, Clifford Buttschardt wrote:

> As you, I am most interested in Brian Beesley's efforts using the sound 
> card instead of some of the DSP units that have attempted to do 9600, 
> Amtor/Pactor.  These tasks should have already been accomplished by the 
> DSP 93 platform by have not!  If this sound card approach does work, I'd 
> be most interested in knowing that fact AND knowing just how difficult it 
> might be to program for BPSK, DBPSK and similar protocols.
> Cliff Buttschardt   W6HDO
> 
> 

A couple of things to consider:

I have been hearing great things about Brian's program - a nice 
achievement. For RTTY, however, it is OK to "copy behind" even by as much 
as one symbol (baud) time. That is not workable for an ARQ system where 
the additional delay (as much as 10 ms) will most definately upset the tight 
timing cycle. However, I'm sure that it is only a matter of time 
until when we will see a solution.

You probably are aware of Bill de Carle's, VE2IQ, work with CCW and BPSK 
using a PC platform for doing DSP - perhaps pushing it to the limit, however,
as the processing speeds go up and prices drop, who knows, one day we might 
all be doing it that way. As Phil has often said, we can get a lot of 
amateurs interested in participating if we can do advanced DSP on a PC 
rather than invest in additional external equipment.

Venturing off the HF digital topic, the issue of doing a fully featured 
9600 baud modems on the DSP-93 is not as obvious. I have looked 
into this possibility with the intention of doing this, but must agree 
with the DSP-93 experts that it is, to say the least, more than a 
challenge. And not for lack of efforts either. The DSP-93 uses a CODEC that 
is programmed at a fixed A/D rate that is not a multiple of the 9600 baud 
clock. This means that it is not possible to ever achieve perfect sync to 
extract exact bit edges. The option that the designers had was to 
oversample the signal in order to increase resolution and thus reduce the 
amount of bit edge jitter. The price to pay is that this eats 
up a lot of DSP clock tics and thus leaves little prospect for doing things 
like HDLC on the DSP. I hope that I have summarized this accurately - 
this is what Frank Perkins, one of the DSP-93 modem designers shared with me.
Someone may want to comment on this.

This problem is not unique to the DSP-93 either. Have a look at the new 
AEA DSP-232 and you will see that they still have an HDLC chip on the 
board.  Guess why? If you look a bit further at other 9600 baud DSP 
applications like for instance the DSP sound card, you see similar 
things such as HDLC emulation being done on the PC, however few do 
attempt this on the DSP.

There is an exception though. With the 9600 baud G3RUH modem for the 
Motorola EVM, Jarkko, OH2LNS, pulled some clever tricks out of the 
hat by utilizing 56K features. He has managed to implemnt both the 
9600 baud modem, HDLC decoder and 19.2K KISS interface all on the DSP. In my 
humble opinion, this is only possible due to the 56K architecture. For 
instance, it has an on-chip UART that takes care of the serial interface. 
Anyone that has succeeded in building a bit-banger UART on a DSP where 
there are high rate interrupts running at the same time, knows the value 
of this bit of hardware. The other bit of hardware that helps here is 
the high speed serial interface for dealing with the CODEC that makes it 
possible to implement very efficient interrupt service routines. In 
addition, the instruction set of this chip is more like a microcontroller 
than a DSP, though works like a DSP. This 9600 baud modem runs on the 
DSP4 which has a 27 MHz clock - the latest version of the EVM has a 66 MHz 
chip, just to give you an idea that the chip is not strapped for clock 
cycles.  

My $0.02, for what it is worth. 

It is important to keep in mind that each platform has its advantages and 
disadvantages. The potential is there, none of it is easy, and the learning 
curve is steep. But it is inviting and ready for exploring - if you have 
the time and patience.

Good luck.

--Johan, KC7WW

From fperkins@onramp.net Tue Feb 27 20:03:54 1996
Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by tapr.org (8.7.4/8.7.3/1.8) with ESMTP id UAA19779 for <hfsig@tapr.org>; Tue, 27 Feb 1996 20:03:47 -0600 (CST)
Received: from 199.184.212.226 (stockyard63.onramp.net [199.184.212.226]) by mailhost.onramp.net (8.7.3/8.6.5) with SMTP id UAA22485 for <hfsig@tapr.org>; Tue, 27 Feb 1996 20:03:37 -0600 (CST)
Date: Tue, 27 Feb 1996 20:03:37 -0600 (CST)
Message-Id: <199602280203.UAA22485@mailhost.onramp.net>
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: fperkins@onramp.net
Subject: Re: [HFSIG:915] Re: QST tidbits
To: hfsig@tapr.org
In-Reply-To: <Pine.OSF.3.91.960227132050.11393C-100000@ucs.orst.edu>
X-Mailer: SPRY Mail Version: 04.00.06.17

Hi Johan,

Here is a couple of cents more:

Re the DSP-93 and AMTOR, I have shown it receiving AMTOR using you TOR
program on several of my DSP-93 videos as seen at the DCC and AMSAT
conferences. The modem side was pretty easy - TOR does the hard part.
I was just wondering if you had done any experimenting with the DSP-93
TOR combo.

Out of frustration in trying to define SW to do an AX.25 FCS 
calculation, I threw a bit of code together for the Bell 202 modem 
on the DSP-93, so I could push raw packets out the DSP-93 UART 
and get a look at the structure of the FCS. In case anyone is 
interested:

  All bytes in the packet EXCEPT the FCS are sent LSB 1st.

  The FCS is sent high byte first, MSB first. The AX.25 spec nicely
  gets around defining this by referring to an obscure CCITT spec.

Based on this quick, rough hack, I don't think there would be any problem
adding HDLC and KISS to the 300 and 1200 bps modems - if someone has the
time and interest to pursue it. For the reasons you explained, I don't
this is practical for 9600 bps.

73 Frank WB5IPM

From k6sti@n2.net  Tue Feb 27 20:48:05 1996
Received: from ravel.n2.net (ravel.n2.net [204.250.22.20]) by tapr.org (8.7.4/8.7.3/1.8) with SMTP id UAA21466 for <hfsig@tapr.org>; Tue, 27 Feb 1996 20:48:01 -0600 (CST)
Received: from ppp179.n2.net (ppp179.n2.net [204.250.22.179]) by ravel.n2.net (8.6.12/8.6.9) with SMTP id SAA26541 for <hfsig@tapr.org>; Tue, 27 Feb 1996 18:48:37 -0800
Date: Tue, 27 Feb 1996 18:48:37 -0800
Message-Id: <199602280248.SAA26541@ravel.n2.net>
X-Sender: k6sti@mail.n2.net
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: hfsig@tapr.org
From: k6sti@n2.net (Brian Beezley)
Subject: Sound Blaster

Johan, using the Creative Labs device driver, signal delay is about 500 ms
on both transmit and receive for a 6-kHz sample rate.  Most of this is in
the DMA buffer, the size of which cannot be made less than 4096 bytes.  The
Creative Labs device driver is not easy to work with.  I had a lot of
trouble getting it to work reliably for continuous conversion despite three
books of documentation and very accessible developer support.  Some crucial
parts of the documentation turned out to be in error and I had to discover
this by experiment.  Had I known all this before I started, I certainly
would have rolled my own driver.  In fact, I still may.

Using the Creative Labs driver also ties you exclusively to Sound Blaster
hardware.  They have a very large share of the sound card market and their
cards are inexpensive, so this isn't much of a problem for desktop
applications.  However, many notebook computers don't use the Creative Labs
Vibra 16 chip.  For these machines there's no way to add an alternate sound
card and therefore no way to run a program written for the Creative Labs
drivers.  This issue has already come up for the Heard Island DXpedition
that wants to take along high-performance RTTY without having to lug around
external RTTY boxes.


                      73--Brian, K6STI
                          k6sti@n2.net

From Robert.Glassey@nmp.nokia.com Wed Feb 28 06:01:14 1996
Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by tapr.org (8.7.4/8.7.3/1.8) with SMTP id GAA17192 for <hfsig@tapr.org>; Wed, 28 Feb 1996 06:01:05 -0600 (CST)
From: Robert.Glassey@nmp.nokia.com
Received: from samail01.nmp.nokia.com (samail01.nmp.nokia.com [131.228.240.6]) by noknic.nokia.com (8.6.9/8.6.9) with ESMTP id NAA11747 for <hfsig@tapr.org>; Wed, 28 Feb 1996 13:33:37 +0200
Received: from  by samail01.nmp.nokia.com with SMTP
	(1.37.109.16/16.2) id AA272446978; Wed, 28 Feb 1996 13:29:38 +0200
X-Openmail-Hops: 2
Date: Wed, 28 Feb 96 11:31:30 +0000
Message-Id: <H00002920138a6d3@MHS>
In-Reply-To: <Pine.OSF.3.91.960227104126.16938F-100000@biggulp.callamer.com>
Subject: Re: QST tidbits
Mime-Version: 1.0
To: hfsig@tapr.org
Content-Type: text/plain; charset=ISO-8859-1; name="Re:"
Content-Transfer-Encoding: quoted-printable

Hi Everyone,

It's about time I made myself know to more that just one or two of you,
since this is a pet topic of mine. I haven't had a chance to review
Brians program, so I'm not sure what it is like or what it can do, but I=

am also working on a RTTY/AMTOR/PACTOR soundblaster program, and am
having some success, althought there is still plently of work to do.

I've been following this group for a while now and am most interested in=

what you guys are getting up to. As Phil has mentioned on this group a
pentium/486 is quite capable of real DSP work, and in fact I have had a
_very_ simple BPSK modem working on a 12 MHZ 286! Programming for the
soundblaster at hardware level on a PC is not trivial, but it is quite
possible, and the DMA and interupts of a PC can be used to our
advantage. I program the interupt code in fixed point assembly and the
UI/protocol stuff in C.

As for when my program will be released, I'm not sure, but we're talking=

6 months to a year away, unless I have a lot of unexpected time on my
hands. At present my program does RTTY demod only, in a very crude
manner.

> As you, I am most interested in Brian Beesley's efforts using the
> sound  card instead of some of the DSP units that have attempted to do=


> 9600,  Amtor/Pactor.  These tasks should have already been
> accomplished by the DSP 93 platform by have not!  If this sound card
> approach does work, I'd  be most interested in knowing that fact AND
> knowing just how difficult it  might be to program for BPSK, DBPSK and=

> similar protocols.
> Cliff Buttschardt   W6HDO
> =


Cheers,

Rob, G0VTQ

From 72253.2602@compuserve.com Wed Feb 28 06:54:24 1996
Received: from arl-img-5.compuserve.com (arl-img-5.compuserve.com [198.4.7.5]) by tapr.org (8.7.4/8.7.3/1.8) with SMTP id GAA19223 for <hfsig@tapr.org>; Wed, 28 Feb 1996 06:54:22 -0600 (CST)
Received: by arl-img-5.compuserve.com (8.6.10/5.950515)
	id HAA05901; Wed, 28 Feb 1996 07:53:45 -0500
Date: 28 Feb 96 07:51:59 EST
From: Peter Schulze <72253.2602@compuserve.com>
To: HFSIG <hfsig@tapr.org>
Subject: Re: [HFSIG:917] Sound Blaster
Message-ID: <960228125158_72253.2602_EHJ92-2@CompuServe.COM>

Brian,

you should consider to switch to Windows, there you have a very easy API to 
interface with the soundcards and you dont have to worry about the make and
details.
Together with the INTEL native DSP library you get a very easy no headache 
DSP setup.

Peter

From 72253.2602@compuserve.com Wed Feb 28 06:54:25 1996
Received: from arl-img-5.compuserve.com (arl-img-5.compuserve.com [198.4.7.5]) by tapr.org (8.7.4/8.7.3/1.8) with SMTP id GAA19224 for <hfsig@tapr.org>; Wed, 28 Feb 1996 06:54:22 -0600 (CST)
Received: by arl-img-5.compuserve.com (8.6.10/5.950515)
	id HAA05923; Wed, 28 Feb 1996 07:53:47 -0500
Date: 28 Feb 96 07:51:54 EST
From: Peter Schulze <72253.2602@compuserve.com>
To: HFSIG <hfsig@tapr.org>
Subject: Digital Journal
Message-ID: <960228125153_72253.2602_EHJ92-1@CompuServe.COM>


>You mentioned the digital journal in a TAPR
>SIG .... who's digital journal... available in US???

The digital journal is the monthly publication of :

International Digital Radio Association
P.O. Box 2550
Goldenrod, Florida 32733-2550 -- U.S.A.
Office: +1-407-677-7000
Fax: +1-407-671-0194
Internet E-Mail Address: adrs@iea.com
WWW Page: http://www.iea.com/~adrs 

The journal has its own WWW page:
http://home.earthlink.net/~n2hos/

73 Peter TY1PS


From forrerj@ucs.orst.edu Wed Feb 28 10:58:31 1996
Received: from ucs.orst.edu (forrerj@UCS.ORST.EDU [128.193.4.5]) by tapr.org (8.7.4/8.7.3/1.8) with SMTP id KAA29983 for <hfsig@tapr.org>; Wed, 28 Feb 1996 10:54:56 -0600 (CST)
Received: by ucs.orst.edu; (5.65v3.2/1.1.8.2/24Sep94-1201PM)
	id AA03003; Wed, 28 Feb 1996 08:54:31 -0800
Date: Wed, 28 Feb 1996 08:54:31 -0800 (PST)
From: Johan Forrer <forrerj@ucs.orst.edu>
To: hfsig@tapr.org
Subject: Re: [HFSIG:916] Re: QST tidbits
In-Reply-To: <199602280203.UAA22485@mailhost.onramp.net>
Message-Id: <Pine.OSF.3.91.960228084251.27038A-100000@ucs.orst.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Frank,


On Tue, 27 Feb 1996 fperkins@onramp.net wrote:

> Hi Johan,
> 
> Here is a couple of cents more:
> 
> Re the DSP-93 and AMTOR, I have shown it receiving AMTOR using you TOR
> program on several of my DSP-93 videos as seen at the DCC and AMSAT
> conferences. The modem side was pretty easy - TOR does the hard part.
> I was just wondering if you had done any experimenting with the DSP-93
> TOR combo.

Besides just trying it out and getting it to work, I have not done much 
further. One of those things on the "to do list" that I hope to explore 
one of these days. I also need to update the Pactor.

If anyone does not know about it yet - the source code for the TOR 
modes that I wrote has been available in the "TORLIB.ZIP" file on the 
HFSIG upload area for some time. It is for the sound card DSP board, 
though can be used with any modem with a bit of work. Feel free to use it 
and share your experiences.

> 
> Out of frustration in trying to define SW to do an AX.25 FCS 
> calculation, I threw a bit of code together for the Bell 202 modem 
> on the DSP-93, so I could push raw packets out the DSP-93 UART 
> and get a look at the structure of the FCS. In case anyone is 
> interested:
> 
>   All bytes in the packet EXCEPT the FCS are sent LSB 1st.
> 
>   The FCS is sent high byte first, MSB first. The AX.25 spec nicely
>   gets around defining this by referring to an obscure CCITT spec.

Thanks for the feedback Frank. I have scratched my head over that one as 
well. I recently have made a hack to Pawel's AX25DRV program, which is a 
TSR that reads the raw bit stream from the serial port. This program very 
nicely unscrambles the raw data and provides the interrupt hook for NOS's 
"attach" command. This way I had a TI320C26 DSK running on HF Packet (of 
course only reading the mail). This agrees with your next comment.

> 
> Based on this quick, rough hack, I don't think there would be any problem
> adding HDLC and KISS to the 300 and 1200 bps modems - if someone has the
> time and interest to pursue it. For the reasons you explained, I don't
> this is practical for 9600 bps.
> 
> 73 Frank WB5IPM
> 
> 

Not to pursue this thread much further here on HFSIG, I just wanted to 
leave this with a last comment. I wonder if the 9600 baud DSP-93 modem 
problem could not be solved using a multirate technique, i.e., a number 
of downsample/upsample filters with the appropiate fractional ratio to 
get you to an exact multiple of 9600. This might consume less clock 
cycles and leave the possibilities for other features. Just a thought.

--Johan

 

From forrerj@ucs.orst.edu Wed Feb 28 10:59:30 1996
Received: from ucs.orst.edu (forrerj@UCS.ORST.EDU [128.193.4.5]) by tapr.org (8.7.4/8.7.3/1.8) with SMTP id KAA00198 for <hfsig@tapr.org>; Wed, 28 Feb 1996 10:59:28 -0600 (CST)
Received: by ucs.orst.edu; (5.65v3.2/1.1.8.2/24Sep94-1201PM)
	id AA31331; Wed, 28 Feb 1996 08:59:25 -0800
Date: Wed, 28 Feb 1996 08:59:24 -0800 (PST)
From: Johan Forrer <forrerj@ucs.orst.edu>
To: hfsig@tapr.org
Subject: Re: [HFSIG:917] Sound Blaster
In-Reply-To: <199602280248.SAA26541@ravel.n2.net>
Message-Id: <Pine.OSF.3.91.960228085514.27038B-100000@ucs.orst.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Brian,

Nice to hear from you on the list. I think your experiences with the CL 
products at that level basic level is quite interesting. 

You certainly are in ahead of the pack with your work - hope a solution 
to the sampling problem can be found.

Keep us posted on your activities.

--Johan

From cbuttsch@biggulp.callamer.com Wed Feb 28 12:27:06 1996
Received: from biggulp.callamer.com (cbuttsch@biggulp.callamer.com [199.74.141.2]) by tapr.org (8.7.4/8.7.3/1.8) with ESMTP id MAA04449 for <hfsig@tapr.org>; Wed, 28 Feb 1996 12:27:01 -0600 (CST)
Received: (from cbuttsch@localhost) by biggulp.callamer.com (8.7.4/8.7.3) id KAA14748; Wed, 28 Feb 1996 10:26:52 -0800 (PST)
Date: Wed, 28 Feb 1996 10:26:52 -0800 (PST)
From: Clifford Buttschardt <cbuttsch@biggulp.callamer.com>
To: Brian Beezley <k6sti@n2.net>
cc: hfsig@tapr.org
Subject: Re: [HFSIG:917] Sound Blaster
In-Reply-To: <199602280248.SAA26541@ravel.n2.net>
Message-ID: <Pine.OSF.3.91.960228102227.23115G-100000@biggulp.callamer.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Brian, Johan and the group..  First Brian, I have both of your 
E-messages and especially appreciate the comments to hfsig regarding the 
sound blaster.  I am more than willing to wait until a laptop can be 
arranged to do the job.  Johans explaination of the difficulties with the 
DSP 93 on 9600 baud as well as AMTOR/PACTOR was even more interesting.  
Thanks to all. Cliff W6HDO

From cbuttsch@biggulp.callamer.com Wed Feb 28 15:53:17 1996
Received: from biggulp.callamer.com (cbuttsch@biggulp.callamer.com [199.74.141.2]) by tapr.org (8.7.4/8.7.3/1.8) with ESMTP id PAA13487 for <hfsig@tapr.org>; Wed, 28 Feb 1996 15:53:13 -0600 (CST)
Received: (from cbuttsch@localhost) by biggulp.callamer.com (8.7.4/8.7.3) id NAA08901; Wed, 28 Feb 1996 13:52:46 -0800 (PST)
Date: Wed, 28 Feb 1996 13:52:45 -0800 (PST)
From: Clifford Buttschardt <cbuttsch@biggulp.callamer.com>
To: Robert.Glassey@nmp.nokia.com
cc: hfsig@tapr.org
Subject: Re: [HFSIG:918] Re: QST tidbits
In-Reply-To: <H00002920138a6d3@MHS>
Message-ID: <Pine.OSF.3.91.960228135145.5274E-100000@biggulp.callamer.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Your comments regarding BPSK and demods without processor well noted!
Thanks....Cliff Buttschardt   W6HDO

From crlbyers@garlic.com Wed Feb 28 19:10:27 1996
Received: from garlic.com (garlic.com [165.227.35.130]) by tapr.org (8.7.4/8.7.3/1.8) with ESMTP id TAA21689 for <hfsig@tapr.org>; Wed, 28 Feb 1996 19:10:24 -0600 (CST)
Received: from no1nos2 by garlic.com (8.7.4/4.03)
          id RAA62910; Wed, 28 Feb 1996 17:10:21 -0800
Message-ID: <3134FB62.6E19@garlic.com>
Date: Wed, 28 Feb 1996 17:03:30 -0800
From: Carol Byers <crlbyers@garlic.com>
Organization: no1no's
X-Mailer: Mozilla 2.0Ib6a (Win16; I)
MIME-Version: 1.0
To: hfsig@tapr.org
Subject: Re: [HFSIG:917] Sound Blaster
References: <199602280248.SAA26541@ravel.n2.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hey Brian,

When you were real young, did you live on o'Dell street in Edison Park, 
Il.??

From fperkins@onramp.net Wed Feb 28 21:59:07 1996
Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by tapr.org (8.7.4/8.7.3/1.8) with ESMTP id VAA01027 for <hfsig@tapr.org>; Wed, 28 Feb 1996 21:59:05 -0600 (CST)
Received: from 199.184.212.207 (stockyard44.onramp.net [199.184.212.207]) by mailhost.onramp.net (8.7.3/8.6.5) with SMTP id UAA26330 for <hfsig@tapr.org>; Wed, 28 Feb 1996 20:57:43 -0600 (CST)
Date: Wed, 28 Feb 1996 20:57:43 -0600 (CST)
Message-Id: <199602290257.UAA26330@mailhost.onramp.net>
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: fperkins@onramp.net
Subject: Re: [HFSIG:921] Re: QST tidbits
To: hfsig@tapr.org
In-Reply-To: <Pine.OSF.3.91.960228084251.27038A-100000@ucs.orst.edu>
X-Mailer: SPRY Mail Version: 04.00.06.17

Hi Johan,

This (up/down resampling) might be possible. It would be great if the AIO 
sampling rate was capable of fine adjustment (corse adjustment is possible but 
would "shock" the DSP calculations). With fine adjustment, 
you could lock the AIO sampling rate to the locally extacted clock and get good 
results with a much lower sampling rate.

73 Frank WB5IPM

From N0AOT@aol.com Wed Feb 28 23:57:14 1996
Received: from emout09.mail.aol.com (emout09.mx.aol.com [198.81.11.24]) by tapr.org (8.7.4/8.7.3/1.8) with SMTP id XAA07303 for <hfsig@tapr.org>; Wed, 28 Feb 1996 23:57:11 -0600 (CST)
From: N0AOT@aol.com
Received: by emout09.mail.aol.com (8.6.12/8.6.12) id AAA09945; Thu, 29 Feb 1996 00:57:34 -0500
Date: Thu, 29 Feb 1996 00:57:34 -0500
Message-ID: <960229005733_156262947@emout09.mail.aol.com>
To: forrerj@ucs.orst.edu
cc: amsat-bb@amsat.org, hfsig@tapr.org
Subject: Re: Latest news

In a message dated 96-02-27 14:47:19 EST, forrerj@ucs.orst.edu (Johan Forrer)
writes:

>The main problem with 9600 baud is that, besides the modem (which is 
>quite simple), is data and clock recovery and then HDLC decoding. For 
>9600 baud the symbols are very short and ideally one would like to have 
>good edge resolution, say 1/250 of the symbol max jitter. That calls for 
>very heavy duty front end oversampling. That is why the TAPR DSP-93
>needs an outboard TNC to do this. 

>We have been using the Motorola 56002 EVM for this ($150) and have 
>managed to do it all on the DSP chip, i.e. modem + HDLC and serial 
>communications at 19.2K. There is one fellow that tells me he uses it 
>with WISP.

Hi Dr. Johan,

Thanks for the nice note. I had no idea someone already had a 9600 baud modem
running on the EVM! This makes me wonder what else is already available?
Sounds like the EVM is more versatile than the DSP-93...  Does anyone keep a
list/library of all the stuff that is currently available for the EVM? 

If 9600 baud and amtor/pactor are already available, I'll order one tomorrow!
 Then I can use it to develop new stuff besides... Neat! 

In order to recommend a pacsat radio to you, I need to know more about your
requirements. Personally, I am mainly interested in the pacsats for
world-wide email, so the radio requirements and antenna requirements are be
much less than for working ssb and sstv on ao-13, for instance. I have made
minor mods to a Kenwood TM-733a dual bander for pacsat use. These radios are
much cheaper than "real" satellite radios. If you let me know what you want
to do on the satellites, I might be able to help you more...

Thanks Much, 

--Bob, n0aot@amsat.org

From 72253.2602@compuserve.com Thu Feb 29 10:40:13 1996
Received: from arl-img-6.compuserve.com (arl-img-6.compuserve.com [198.4.7.6]) by tapr.org (8.7.4/8.7.3/1.8) with SMTP id KAA04366 for <hfsig@tapr.org>; Thu, 29 Feb 1996 10:39:59 -0600 (CST)
Received: by arl-img-6.compuserve.com (8.6.10/5.950515)
	id LAA09180; Thu, 29 Feb 1996 11:06:00 -0500
Date: 29 Feb 96 11:03:57 EST
From: Peter Schulze <72253.2602@compuserve.com>
To: HFSIG <hfsig@tapr.org>
Subject: Re: Sound Card Interface
Message-ID: <960229160356_72253.2602_EHJ113-3@CompuServe.COM>

Hi Brian,

>Not a bad idea, Peter, except that then I would have to deal with the
>real-time limitations of both the Windows sound interface and the Creative
>Labs device driver it calls.  Although cascaded, perhaps these interfaces
>are better suited for low-delay, continuous, real-time I/O.  I don't know.
>At least in DOS, you can obtain direct access to the sound card hardware
>without asking permission and then do whatever is necessary to get it to
>work.  Apparently due to the demands of game developers, Win95 now
>incorporates a DirectSound interface that lets a program bypass Windows and
>do the same thing.

Directsound won't help you a lot as it is mainly targeted to mix and output
sounds
in sync with screen events. There is nothing in there on the wave input side. 

As somebody mentioned before, as long as you are not tight on timing (read RTTY
for example) 
you can live with the delays, but when you need to keep in pace with an ARQ
protocol
it can become difficult. 
I wonder if anybody ever thought about a new ARQ protocol that works 'one
behind' ? 
I mean, that you prepare the 'answer' block while receiving a block and it is
then sent
next time you are on TX.  Hope you understand what i mean. This would give ample
time
to analyze a recieved block of data and prepare the reply. 

I shall set up some kind of timing loop here one day and see what delays are
involved
when getting wave input under windows with the win drivers... trigger some kind
of signal
on the mic-input under program control and see how long it takes before it
appears 
in the samples.

I see a discussion about  ways to implement AX25 for the new HF modems. 
To my opinion thats a bad track. To much overhead, lack of forward error
correction etc..
It may seem appealing at the first hand to gain easy access to an existing
application
software base, but long time the disadvantages of AX25 will dominate.. 
Same is true for TCP/IP... just to much overhead for low thruput channels. 
Makes no sense to put all effort into faster modems and then eat it up
with protocols that don't fit...

73 Peter

From forrerj@ucs.orst.edu  Thu Feb 29 22:25:24 1996
Received: from PEAK.ORG (root@PEAK.ORG [198.68.23.17]) by tapr.org (8.7.4/8.7.3/1.8) with SMTP id WAA26669 for <hfsig@tapr.org>; Thu, 29 Feb 1996 22:25:19 -0600 (CST)
Received: from p03.t0.monrotel.com (p03.t0.monrotel.com [198.68.25.36]) by PEAK.ORG (8.6.12/8.6.7) with SMTP id QAA08316 for <hfsig@tapr.org>; Thu, 29 Feb 1996 16:51:22 -0800
Message-Id: <199603010051.QAA08316@PEAK.ORG>
X-Sender: forrera@kira.peak.org (Unverified)
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 29 Feb 1996 16:58:30 -0800
To: hfsig@tapr.org
From: forrerj@ucs.orst.edu (Johan Forrer)
Subject: HF data link layer (was:Sound Card Interface)

Peter,

>As somebody mentioned before, as long as you are not tight on timing (read RTTY
>for example) 
>you can live with the delays, but when you need to keep in pace with an ARQ
>protocol
>it can become difficult. 

Yes that is correct. Pactor I for instance has a frame cycle time of 1250
ms, the data being 960 ms, thus the "dead time" is some 290 ms. The "dead
time" is taken up by a) propagation time to the receiver, b) the reverse
channel control command, c) tx/rx changeover delays, d) sending the control
signal. Subtracting the time for sending the control signal, i.e., 120 ms,
leaves 170 ms for all the propagation times and changeover times. This
scheme allows for a 20,000 km maximum distance point-to-point. It is obvious
that any other delays will probably mess things up. 

 
>I wonder if anybody ever thought about a new ARQ protocol that works 'one
>behind' ? 
>I mean, that you prepare the 'answer' block while receiving a block and it is
>then sent
>next time you are on TX.  Hope you understand what i mean. This would give
ample
>time
>to analyze a recieved block of data and prepare the reply. 


There is an ARQ protocol that works like this, i.e., only way down the line
does the receiver request certain blocks to be resent. I think this is
called "Go back N" ARQ. Implementation of these things gets complicated
rather quickly because one have to assume that the reverse channel is also
subject to being corrupted. So there are a lot of shuffling going on for
missing parts. I hope I never have to do one of those :-)


>I see a discussion about  ways to implement AX25 for the new HF modems. 
>To my opinion thats a bad track. To much overhead, lack of forward error
>correction etc..
>It may seem appealing at the first hand to gain easy access to an existing
>application
>software base, but long time the disadvantages of AX25 will dominate.. 

I don't think you have to worry much about this Peter. What we have done was
only a quick and dirty hack to try out some modems. 

You must have been following the discussions over the past few weeks on the
proposed new data link layer. We were discussing certain parts of the frame,
i.e., the sync vector and the reverse channel signaling. What goes inbetween
these are still undecided. Ideally though I would like to see convolutional
codes with the ability to use punctured codes when conditions are good.  

These are only suggestions, so it's open for discussion. Perhaps you would
like to share your ideas??


>Same is true for TCP/IP... just to much overhead for low thruput channels. 

I think you mean encapsulating TCP/IP in the existing schemes, which I agree
is not workable. Hopefully there would be a way to minimize the overhead,
yet retain the ability to utilize networking capabilitie with the scheme
proposed above. 

Again, we welcome input on this topic.


--Johan

From cbuttsch@slonet.org Thu Feb 29 22:29:26 1996
Received: from biggulp.callamer.com (root@biggulp.callamer.com [199.74.141.2]) by tapr.org (8.7.4/8.7.3/1.8) with ESMTP id WAA26928 for <hfsig@tapr.org>; Thu, 29 Feb 1996 22:29:20 -0600 (CST)
Received: (from cbuttsch@localhost) by biggulp.callamer.com (8.7.4/8.7.3) id RAA04311; Thu, 29 Feb 1996 17:02:50 -0800 (PST)
Date: Thu, 29 Feb 1996 17:02:49 -0800 (PST)
From: Clifford Buttschardt <cbuttsch@slonet.org>
X-Sender: cbuttsch@biggulp.callamer.com
To: David Nulton <dnult@atlas.axiom.net>
cc: Johan Forrer <forrerj@ucs.orst.edu>, hfsig@tapr.org
Subject: Re: Need Recommendation for DSP Design 
In-Reply-To: <199602291759.LAA27489@atlas.axiom.net>
Message-ID: <Pine.OSF.3.91.960229165312.19842C-100000@biggulp.callamer.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi David.  Thanks for the suggestion on the 320.  I did not know that 16 
bit processing was used and therefore switching is needed to use 8 bit 
EPROMS.  Good suggestion.  I am trying to develop some newer BiPhase 
Frequency Shift decoding protocols and at the same time, keep it simple 
enough to where ordinary people can participate.  In general, we have 
been using the computer to maximum ability and making up the difference 
in hardware.  So far we have reached the level where a Pentium is 
required and have backed down to where 486/66 units will operate.  This 
still seems to exceed the capabilities of the 320.  We have gotten this 
far by "stealth"---using clever programming, but I have no clue if the 
existing TMS320C25 programs have tried to increase speed in a like manner.
    Thanks again for your help.  Cliff Buttschardt W6HDO Cal Poly, SLO, CA

